findExeutable does not respect order of search path on Windows
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?
Trac metadata
Trac field | Value |
---|---|
Version | 6.10.2 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | libraries/directory |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |