[Haskell-cafe] Re: ANN: HSH 1.2.0

[John Goerzen]

On Tue, Mar 13, 2007 at 10:51:47AM +0000, Simon Marlow wrote:
> Before I answer the question, if you don't mind I'll quote from my own 
> message:

[ snip ]

> So ideally we'd have a version of runInteractiveProcess that didn't create 
> all three pipes, and then it would be easy to program your example.  
> Unfortunately we don't have such a function, but it's still possible to 
> code up your example - you just end up with too many pipes and you'd need 
> some Haskell threads to act as dummy "processes" between the extra pipe 
> ends.  I'm aware this isn't a satisfactory solution, for various reasons.

Right, sorry, that makes sense.  I don't immediately know what such a
function should look like, but yeah, I don't really want to get into
having data mover threads in this.

One other weakness about the current setup is that runInteractiveProcess
is a sort of all-or-nothing approach.  You can get stdin, stdout, and
stderr redirected to Handles -- or you can use a different function and
not have them redirected to Handles.  You can't get just stdin and
stdout redirected with stderr still going to the console, and you can't
get stdout and stderr redirected to the same Handle.

I almost wonder if a lower-level equivalent to dup2() and pipe() is
warranted.

Also, there is a weakness in waitForProcess.  You'll note that the POSIX
waitpid() function (getProcessStatus in Haskell) returns more
information than waitForProcess does.  Specifically, it can return
whether a process was killed by a signal, and if so, which signal.

A glance at the source code for waitForProcess revealed that it was
simply using -1 for all signals.

Perhaps it would be better to at least use the bash convention of 128+n,
where n is the signal number.  But even better, the Posix type
ProcessStatus could be brought into the main libraries and used here.

-- John