Proposal: overhaul System.Process

Simon Marlow marlowsd at
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 mailing list