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 <ian@well-typed.com> wrote:

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