> To me, and perhaps only to me, the "expected behavior" would be that if you
> sent an EOF down the input pipe(mbx) the subprocess would exit (i.e.,
> closing the input mailbox would terminate the process). I don't know why,
> but that seems like the right way. I guess some of this has to do with what
> is "expected" behavior when you see the ^Z in an mbx...Just my 2 cents...
It looks like Charles Lane's code'd preserve the current behavior: if you
send an EOF to DCL and don't specifically trap it, it'll quit. If you
send an EOF to some program running in the subprocess, it'll see an EOF
on stdin, and can react as it wants.
My concern is with stripping out EOFs that the subprocess sends back to you.
While it does solve the problem of multiple EOFs being passed to the parent
as its descendants complete, it'll break cases where the multiple EOFs are
intentionally sent by a single child (typically as a sort-of OOB signal to the
parent). I'm always happy to let you filter out junk, but get uneasy when
we make it mandatory.
Regards,
Charles Bailey [EMAIL PROTECTED]
