Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#7327 closed bug (worksforme)

Inconsistent behavior for relative paths in runProcess

Reported by: snoyberg Owned by:
Priority: normal Milestone: 7.8.1
Component: libraries/process Version: 7.6.1
Keywords: Cc: johan.tibell@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


This was initially reported as a bug in cabal:

The relevant fix demonstrates the issue:

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.

Change History (6)

comment:1 Changed 5 years ago by igloo

difficulty: Unknown
Milestone: 7.8.1
Status: newinfoneeded

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 "./" [] (Just "sub")
                           Nothing Nothing Nothing Nothing
          ec <- waitForProcess ph
          print ec

$ cat    

echo Running root
$ cat sub/

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

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

comment:2 Changed 5 years ago by 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.

comment:3 Changed 4 years ago by tibbe

Cc: johan.tibell@… added

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 "./" [] (Just "sub")
                           Nothing Nothing Nothing Nothing
          ec <- waitForProcess ph
          print ec
$ cat >

echo Running root
$ mkdir sub
$ cat > sub/

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")
 ,("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")
 ,("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")
 ,("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.

comment:4 Changed 4 years ago by 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?

comment:5 Changed 4 years ago by igloo

Resolution: worksforme
Status: infoneededclosed

As far as I can see, everything is working correctly here.

comment:6 Changed 4 years ago by Blaisorblade

runProcess behavior is however still undocumented: — should I open another bug for that?

We're still observing symptoms, but the behavior might have been fixed in recent versions of libraries for Linux (different Linux machines, with different library versions, show different behavior in

Note: See TracTickets for help on using tickets.