Zsh Mailing List Archive
Messages sorted by:
Re: exit value of intermediate program in pipe
- X-seq: zsh-users 1508
- From: Bernd Eggink <eggink@xxxxxxxxxxxxxx>
- To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- Subject: Re: exit value of intermediate program in pipe
- Date: Mon, 04 May 1998 14:03:07 +0200
- Cc: zsh-users@xxxxxxxxxxxxxxx
- Organization: RRZ Uni Hamburg
- References: <199805022224.QAA03113@xxxxxxxxxxxxxxxxxxxxxx> <980502190831.ZM29269@xxxxxxxxxxxxxxxxxxxxxxx> <19980503021749.21621@xxxxxxxxxxxxxxxxxxxx> <980503023014.ZM31001@xxxxxxxxxxxxxxxxxxxxxxx> <19980503181509.09250@xxxxxxxxxxxxxxxxxxxx> <980503183549.ZM1342@xxxxxxxxxxxxxxxxxxxxxxx> <19980504005404.54023@xxxxxxxxxxxxxxxxxxxx> <354D8DBF.F1F79617@xxxxxxxxxxxxxxxxxx> <980504044259.ZM3556@xxxxxxxxxxxxxxxxxxxxxxx>
- Sender: rz2a022@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?
> } 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
Regionales Rechenzentrum der Uni Hamburg
Messages sorted by: