Opened 19 months ago

Closed 10 months ago

Last modified 8 months 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 Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

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.

Change History (6)

comment:1 Changed 13 months ago by igloo

  • Difficulty set to Unknown
  • Milestone set to 7.8.1
  • Status changed from new to infoneeded

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?

comment:2 Changed 12 months 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 12 months 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 "./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.

comment:4 Changed 12 months 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 10 months ago by igloo

  • Resolution set to worksforme
  • Status changed from infoneeded to closed

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

comment:6 Changed 8 months ago by Blaisorblade

runProcess behavior is however still undocumented: http://hackage.haskell.org/packages/archive/process/latest/doc/html/System-Process.html#v:runProcess — 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 https://github.com/haskell/cabal/issues/1458#issuecomment-23616162).

Note: See TracTickets for help on using tickets.