Ticket #3186 (closed bug: fixed)
findExeutable does not respect order of search path on Windows
|Reported by:||duncan||Owned by:||simonmar|
|Type of failure:||Difficulty:||Unknown|
|Test Case:||Blocked By:|
On Windows findExeutable is behaving rather strangely.
From a command line window (ie not MSYS):
H:\>echo %PATH% C:\Program Files\MiKTeX 2.7\miktex\bin; C:\WINDOWS\system32; C:\WINDOWS; C:\WINDOWS\System32\Wbem; C:\Program Files\QuickTime\QTSystem\; c:\Program Files\Microsoft SQL Server\90\Tools\binn\; C:\Program Files\MATLAB\R2009a\bin; C:\Program Files\MATLAB\R2009a\bin\win32; C:\Program Files\Haskell\bin; D:\dcoutts\ghc-6.10.1\bin; D:\dcoutts\Gtk2Hs\bin; D:\dcoutts\bin
(formatted onto multiple lines for clarity)
Now it appears I've got three versions of haddock installed:
H:\>where haddock C:\Program Files\Haskell\bin\haddock.exe D:\dcoutts\ghc-6.10.1\bin\haddock.exe D:\dcoutts\bin\haddock.exe
However in ghci:
H:\>ghci Prelude> System.Directory.findExecutable "haddock" Just "D:\\dcoutts\\GHC-61~1.1\\bin\\haddock.exe"
But this is bonkers! The version it has found is not in the first directory on the search path.
I don't think it's related to the global/user split in the Windows %PATH%. All of the dirs containing haddock.exe are in the user portion of my %PATH%.
On Windows System.Directory.findExecutable uses the SearchPathA Win32 function. The MSDN docs mention that it searches system and the current dirs first and has some "safe" search mode but none of those things seem to be relevant here.
This problem confuses users of Cabal which uses findExecutable to find build tools. See [this thread http://haskell.org/pipermail/cabal-devel/2009-April/005158.html] from the cabal mailing list.
Perhaps we should just use the pure Haskell version that we use on non-Windows systems. Still, it'd be nice to reflect properly the Windows search path semantics if it's not as simple as looking in the %PATH%.
Actually the semantics are pretty weird. Consider this...
Let's cut down to just two versions of haddock:
H:\>where haddock C:\Program Files\Haskell\bin\haddock.exe D:\dcoutts\ghc-6.10.1\bin\haddock.exe
Now lets see what versions we've got where:
H:\>"C:\Program Files\Haskell\bin\haddock.exe" --version Haddock version 2.1.0, (c) Simon Marlow 2006 Ported to use the GHC API by David Waern 2006-2008 H:\>D:\dcoutts\ghc-6.10.1\bin\haddock.exe --version Haddock version 2.3.0, (c) Simon Marlow 2006 Ported to use the GHC API by David Waern 2006-2008
As expected, just running haddock from the command line gives us the first one:
H:\>haddock --version Haddock version 2.1.0, (c) Simon Marlow 2006 Ported to use the GHC API by David Waern 2006-2008
Now in ghci:
Prelude> System.Process.runCommand "haddock --version" Haddock version 2.1.0, (c) Simon Marlow 2006 Ported to use the GHC API by David Waern 2006-2008
That's fine. It's the first one and consistent with running from the command line (internally runCommand uses the command processor).
But now try this:
Prelude> System.Process.runProcess "haddock" ["--version"] Nothing Nothing Nothing Nothing Nothing Haddock version 2.3.0, (c) Simon Marlow 2006 Ported to use the GHC API by David Waern 2006-2008
WT!? Where did that come from? It's using a different search path from the command interpreter. This one however is consistent with the findExecutable function (as it is supposed to be).
No idea what is going on. Can anyone else reproduce or explain this?