Inconsistent behavior for relative paths in runProcess

[snoyberg]

This was initially reported as a bug in cabal:

 https://github.com/haskell/cabal/issues/1058

The relevant fix demonstrates the issue:

 https://github.com/snoyberg/cabal/commit/48082b90726093298df8559b365ed08805ca6d8f

It seems that on Linux, a relative path for the executable is derived from the new working directory, whereas on Mac it is derived from the old working directory. (I have not tested on other systems.) Ideally, the behavior would be consistent across OSes, which IMO the more intuitive behavior being the current Mac behavior. The simplest solution would be to always turn the relative paths into absolute paths before changing working directories. However, doing so may introduce a performance hit.

Alternatively, a documentation fix would be good so that it's at least obvious that behavior is platform-specific. I can write a patch for either the change in behavior or the updated documentation, I'd just like to know which is preferred.

[igloo]

I'm confused; this behaves the same on Linux and OS X for me:

$ cat q.hs        

import System.Process

main :: IO ()
main = do ph <- runProcess "./runme.sh" [] (Just "sub")
                           Nothing Nothing Nothing Nothing
          ec <- waitForProcess ph
          print ec

$ cat runme.sh    
#!/bin/sh

echo Running root
$ cat sub/runme.sh
#!/bin/sh

echo Running in sub
$ ghc --make q     
$ ./q             
Running in sub
ExitSuccess
$ 

Can you tell me how I can reproduce the problem, please?

[snoyberg]

That should reproduce the problem. I don't actually have access to a Mac system, and therefore never personally reproduced this difference in behavior across OSes. I've asked Johan to see if he's still able to reproduce the issue and comment back on this ticket.

[tibbe]

I tried to reproduce the problem, but unfortunately I get a segfault!:

$ cd tmp
$ cat > q.hs
import System.Process

main :: IO ()
main = do ph <- runProcess "./runme.sh" [] (Just "sub")
                           Nothing Nothing Nothing Nothing
          ec <- waitForProcess ph
          print ec
$ cat > runme.sh
#!/bin/sh

echo Running root
$ mkdir sub
$ cat > sub/runme.sh
#!/bin/sh

echo Running in sub
$ ghc --make q 
[1 of 1] Compiling Main             ( q.hs, q.o )
Linking q ...
$ ./q
ExitFailure 127
$ ghc --info
 [("Project name","The Glorious Glasgow Haskell Compilation System")
 ,("GCC extra via C opts"," -fwrapv")
 ,("C compiler command","/usr/bin/gcc")
 ,("C compiler flags"," -m64 -fno-stack-protector  -m64")
 ,("ar command","/usr/bin/ar")
 ,("ar flags","clqs")
 ,("ar supports at file","@ArSupportsAtFile@")
 ,("touch command","touch")
 ,("dllwrap command","/bin/false")
 ,("windres command","/bin/false")
 ,("perl command","/usr/bin/perl")
 ,("target os","OSDarwin")
 ,("target arch","ArchX86_64")
 ,("target word size","8")
 ,("target has GNU nonexec stack","False")
 ,("target has .ident directive","True")
 ,("target has subsections via symbols","True")
 ,("LLVM llc command","llc")
 ,("LLVM opt command","opt")
 ,("Project version","7.6.2")
 ,("Booter version","7.4.2")
 ,("Stage","2")
 ,("Build platform","x86_64-apple-darwin")
 ,("Host platform","x86_64-apple-darwin")
 ,("Target platform","x86_64-apple-darwin")
 ,("Have interpreter","YES")
 ,("Object splitting supported","YES")
 ,("Have native code generator","YES")
 ,("Support SMP","YES")
 ,("Unregisterised","NO")
 ,("Tables next to code","YES")
 ,("RTS ways","l debug  thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn")
 ,("Leading underscore","YES")
 ,("Debug on","False")
 ,("LibDir","/usr/local/lib/ghc-7.6.2")
 ,("Global Package DB","/usr/local/lib/ghc-7.6.2/package.conf.d")
 ,("Gcc Linker flags","[\"-m64\"]")
 ,("Ld Linker flags","[\"-arch\",\"x86_64\"]")
 ]

OS X 10.8.3.

[igloo]

Are you sure that's a segfault, rather than an error because the shell scripts aren't executable?

If so, do you know which process is segfaulting?