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