Proposal: overhaul System.Process
marlowsd at gmail.com
Wed Apr 23 16:27:24 EDT 2008
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
However, I can certainly include the arguments and the exit code in the
exception, which I'm not currently doing.
More information about the Libraries