No subject

...
> If I could somehow arrange to detect EOF when /tmp/exitpipe is
> closed, then I might as well redirect 1 and 2 to FIFOs and wait
> for them to EOF, collecting the output.
> 
> However, all of my experiments suggest that there is simply no
> way in Haskell to detect the closing of the write end of a FIFO.
> With `openFileBlocking', one can detect when a FIFO is *opened*;
> but not when it is closed.

It looks to me like our colleague in another followup may have it
working in an example.  I have run into some trouble myself, with
an example program demonstrating the approach I proposed.  With a 
pre-existing named pipe, that I would just keep using, for whatever
reason it worked the first time, failed the second, and so forth,
working every other time.  If the test program created the named
pipe, it failed every time.  There are probably reasons for all this,
but I haven't looked very hard.

That was using "withFile".  If I use POSIX I/O, it works fine.
So it looks to me like there is indeed a way in Haskell to detect
a closed FIFO, it just may not be Haskell I/O without a lot more
work ironing out the possible causes of failure.

I believe that doesn't need to be a problem for you, though, because
1) your application is by nature exclusive to POSIX platforms, and
2) you need the named pipe only to detect command process exit, and
you can still apply Haskell I/O to the more interesting data that
accumulates in the command output disk file.

And there may be an answer for my problems with Haskell I/O.  Could
be as simple as using openFileBlocking, which apparently isn't supported
in the ghc I'm using.  Could have something to do with the fine points
of named pipes - for example, I believe you're supposed to open them
O_RDWR in situations you'd think would call for O_READONLY.  (Though
the latter worked for me with POSIX I/O.)

While I'm here ... I share the concern expressed in an earlier followup
about the outputs from bash in runInteractiveProcess.  This looks like
a feature of runInteractiveProcess that makes it intrinsically something
like a "code smell".  input-only and output-only processes are commonly
used and fairly tractable, where input-output processes are unusual and
and fragile, so it's an unfortunate convenience.  I think the idea is
that you'd use createProcess specifying only the input redirection.

	Donn