[GHC] #3186: findExeutable does not respect order of search path on Windows

[GHC]

#3186: findExeutable does not respect order of search path on Windows
--------------------+-------------------------------------------------------
Reporter:  duncan   |          Owner:                     
    Type:  bug      |         Status:  new                
Priority:  normal   |      Component:  libraries/directory
 Version:  6.10.2   |       Severity:  normal             
Keywords:           |       Testcase:                     
      Os:  Windows  |   Architecture:  Unknown/Multiple   
--------------------+-------------------------------------------------------
 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 [http://msdn.microsoft.com/en-us/library/aa365527.aspx 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?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3186>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler