<div dir="ltr"><div style>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.</div>
<div><br></div>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.<div style>
<br></div><div style>That said, I'm in favor of this patch because it's still better than the current situation.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Apr 28, 2013 at 7:06 PM, Ian Lynagh <span dir="ltr"><<a href="mailto:ian@well-typed.com" target="_blank">ian@well-typed.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi all,<br>
<br>
Currently, if you try to use rawSystem to run a program that doesn't<br>
exist, you will just get a bad error code as a result, e.g. this<br>
program:<br>
<br>
import System.IO.Error<br>
import System.Process<br>
<br>
main :: IO ()<br>
main = do (rawSystem "/bin/true" [] >>= print)<br>
`catchIOError` \e -> putStrLn ("Exc: " ++ show e)<br>
(rawSystem "/bin/false" [] >>= print)<br>
`catchIOError` \e -> putStrLn ("Exc: " ++ show e)<br>
(rawSystem "/non/existent" [] >>= print)<br>
`catchIOError` \e -> putStrLn ("Exc: " ++ show e)<br>
putStrLn "Done"<br>
<br>
prints:<br>
<br>
ExitSuccess<br>
ExitFailure 1<br>
ExitFailure 127<br>
Done<br>
<br>
However, if we are on a platform that supports vfork, then we can pass<br>
information from the child process back to the parent process as they<br>
share address space. With the attached patch we instead get:<br>
<br>
ExitSuccess<br>
ExitFailure 1<br>
Exc: resolveProcessHandle: does not exist (No such file or directory)<br>
<br>
(and it should be easy to also get "/non/existent" in the exception).<br>
<br>
<br>
If there are platforms that don't support vfork, then they will still<br>
give the old output. I haven't yet looked at whether we can also get<br>
good exceptions on Windows (the patch won't build on Windows yet; I<br>
still need to update the Windows-specific code).<br>
<br>
I think that despite the possibility that some platforms may not be able<br>
to support it, we should provide the better behaviour on platforms that<br>
do.<br>
<br>
What do you think?<br>
And do you have any other comments on the patch?<br>
<br>
(this proposal was inspired by<br>
<a href="http://hackage.haskell.org/trac/ghc/ticket/7859" target="_blank">http://hackage.haskell.org/trac/ghc/ticket/7859</a>).<br>
<br>
<br>
Suggested discussion deadline: Mon 13 May 2013.<br>
<br>
<br>
Thanks<br>
<span class="HOEnZb"><font color="#888888">Ian<br>
<br>
</font></span><br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div>