Opened 3 years ago

Closed 23 months ago

Last modified 20 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 Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

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 2 years 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 2 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 2 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 "./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 2 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 23 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 20 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.