Re: exit value of intermediate program in pipe

[Bernd Eggink <eggink@xxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> On May 4, 11:43am, Bernd Eggink wrote:
> } Subject: Re: exit value of intermediate program in pipe
> }
> } Sweth Chandramouli wrote:
> } > > The last problem is that grep won't exit until it sees EOF on its stdin,
> } > > but >&p dups the coproc input without actually closing it.
> }
> } In ksh, the normal way to kill a coproc is
> }
> }   exec 3<&p 3<-
> 
> Do you mean 3<&- or is <- magic in ksh?  (In zsh, <&- is magic but it only
> works on stdin, it doesn't take a digit to the left.)
> 
> } because just killing the job doesn't close the file descriptor.
> 
> It may not in zsh either.  Anyway, I'm curious about that ksh-ism, because
> it closes the coproc's *output*, not it's input 

Huh? Of course it closes it's input; that's what < means! 

> -- so it's assuming that
> the coproc will die on a "broken pipe" signal, which isn't necessarily
> true.  (As my "yes" example demonstrates, closing the input won't always
> work either, but presumably you don't normally coproc something that is
> going to ignore its input.)
> 
> My "coproc exit" hack works because it closes the old coproc input so as
> to not leak the descriptor.  But it wouldn't have been incorrect for it
> to leave it open, as far as documented behavior goes (which isn't far).
> 
> } In
> } zsh-3.1.3, this doesn't work (a bug, IMHO), but you can kill the job
> } without getting problems.
> 
> If you kill the job, you may lose some of its output.  The only correct
> way is to close the input and let it die in its own good time.

That's what I said - but it doesn't work.

> Can somebody out there who has ksh tell me whether
> 
>         cat |&
>         echo >&p
> 
> causes cat to exit?  That is, does redirection to the coproc make the
> coproc input no longer available to any other process?  

Yes, it does.

[...]

> 
> That is, zsh will re-open the same coproc input as often as you like,
> and never closes it until you start a new coproc.  Does ksh do that?

No.

> } You can have more than one coprocs at a time. Just copy the fd's:
> }
> }   coproc f
> }   exec 3>&p 4<&p   # or whatever numbers you like
> }   coproc g
> 
> Right; if you do that, then my "coproc exit" trick won't stop the first
> coproc, because its input has already been dup'd once and the dup is
> kept open.

So in this case 'kill' seems to be the only way to get rid of the first
n-1 coprocs...

--
Bernd Eggink
Regionales Rechenzentrum der Uni Hamburg
eggink@xxxxxxxxxxxxxxxxxx
http://www.rrz.uni-hamburg.de/eggink/BEggink.html