I definitely support better errors for binary not found, I have always used
a wrapper that waits for the child and logs an error if it was not found,
but all it does is print a msg to stderr.
I still feel like we should learn from the latest python subprocess.py
module. They have fixed a number of subtle bugs over many years and much
testing. They also use pipes to communicate errors back to the parent.
That said, I'm in favor of this patch because it's still better than the
current situation.
On Sun, Apr 28, 2013 at 7:06 PM, Ian Lynagh
Hi all,
Currently, if you try to use rawSystem to run a program that doesn't exist, you will just get a bad error code as a result, e.g. this program:
import System.IO.Error import System.Process
main :: IO () main = do (rawSystem "/bin/true" [] >>= print) `catchIOError` \e -> putStrLn ("Exc: " ++ show e) (rawSystem "/bin/false" [] >>= print) `catchIOError` \e -> putStrLn ("Exc: " ++ show e) (rawSystem "/non/existent" [] >>= print) `catchIOError` \e -> putStrLn ("Exc: " ++ show e) putStrLn "Done"
prints:
ExitSuccess ExitFailure 1 ExitFailure 127 Done
However, if we are on a platform that supports vfork, then we can pass information from the child process back to the parent process as they share address space. With the attached patch we instead get:
ExitSuccess ExitFailure 1 Exc: resolveProcessHandle: does not exist (No such file or directory)
(and it should be easy to also get "/non/existent" in the exception).
If there are platforms that don't support vfork, then they will still give the old output. I haven't yet looked at whether we can also get good exceptions on Windows (the patch won't build on Windows yet; I still need to update the Windows-specific code).
I think that despite the possibility that some platforms may not be able to support it, we should provide the better behaviour on platforms that do.
What do you think? And do you have any other comments on the patch?
(this proposal was inspired by http://hackage.haskell.org/trac/ghc/ticket/7859).
Suggested discussion deadline: Mon 13 May 2013.
Thanks Ian
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries