Proposal: overhaul System.Process

[Neil Mitchell]

Hi

> > What happens to stderr with this function, by the way?
> >  Is it tied to stdout (probably the right thing to do), or to /dev/null,
> > or is it closed (eek!)?
> >
>
>  None of the above :)  Currently it's inherited from the parent.
> Unfortunately it's not easy to tie stderr and stdout to the same pipe -
> createProcess can't do that, and readProcess is defined in terms of it.

It would be useful if they were tied, but not essential - its still a
big improvement over currently.

>  > It would be useful if there was a readProcess variant that gave back a
>  > String each for stdout and stderr.
>
>  Would it be reasonable for that to be the only variant?

If you are implementing this function strictly, then that should be
sufficient. If it were lazy you'd probably want three variants:

1) Only return stdout, and dump stderr onto the normal stderr.

2) Return both stdout and stderr separately.

3) Tie stdout and stderr.

I guess people who want laziness can implement it themselves directly,
taking care to get whatever laziness it is that they want.

Thanks

Neil