Proposal: overhaul System.Process

[David Roundy]

On Wed, Apr 23, 2008 at 01:27:24PM -0700, Simon Marlow wrote:
> David Roundy wrote:
> >On Wed, Apr 23, 2008 at 11:29:42AM -0700, Simon Marlow wrote:
> >>So now we have:
> >>
> >>Prelude System.Process> readProcessMayFail "ls" ["/foo"] ""
> >>(ExitFailure 2,"ls: /foo: No such file or directory\n")
> >>Prelude System.Process> readProcess "ls" ["/foo"] ""
> >>*** Exception: readProcess: ls: failed
> >>
> >>Look ok?
> >
> >Looks fine as an API.  As an implementation, I'd prefer for the exception
> >thrown to include stderr (and wouldn't mind if the output didn't include
> >stderr).  It'd be much nicer if we had:
> >
> >Prelude System.Process> readProcess "ls" ["/foo"] ""
> >*** Exception: readProcess: ls /foo: No such file or directory
> >
> >This would mean that correct programs could use readProcess without
> >sacrificing nice feedback when something unusual happens.  Of course, we
> >can't guarantee that stderr will give any hint as to what went wrong, but
> >that's not our bug.  We could also potentially include both stdout and
> >stderr, or just the last few lines of the stdout/stderr combination.
> 
> Yes, there are a couple of problems here:
> 
>  1. stdout and stderr are tied together, so we don't know which parts
>     of the output are stderr.
> 
>  2. the output might be multi-line, and it's not clear how much or
>     which parts to include.
> 
> The easy answer is just "include it all", but then the error messages 
> could get arbitrarily long and potentially include a lot of superfluous 
> information.
> 
> However, I can certainly include the arguments and the exit code in the 
> exception, which I'm not currently doing.

Why not then leave the stderr out of the output, and just print it to
stderr? It's the standard location to send error output, and I'd hate to
lose it.
-- 
David Roundy
Department of Physics
Oregon State University