From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16114 invoked from network); 4 May 1998 12:19:39 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 4 May 1998 12:19:39 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id IAA21931; Mon, 4 May 1998 08:02:52 -0400 (EDT) Resent-Date: Mon, 4 May 1998 08:02:42 -0400 (EDT) Sender: rz2a022@uni-hamburg.de Message-ID: <354DAE7B.F65FE723@rrz.uni-hamburg.de> Date: Mon, 04 May 1998 14:03:07 +0200 From: Bernd Eggink Organization: RRZ Uni Hamburg X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.2) MIME-Version: 1.0 To: Bart Schaefer CC: zsh-users@math.gatech.edu Subject: Re: exit value of intermediate program in pipe References: <199805022224.QAA03113@ipecac.Central.Sun.COM> <980502190831.ZM29269@candle.brasslantern.com> <19980503021749.21621@astaroth.nit.gwu.edu> <980503023014.ZM31001@candle.brasslantern.com> <19980503181509.09250@astaroth.nit.gwu.edu> <980503183549.ZM1342@candle.brasslantern.com> <19980504005404.54023@astaroth.nit.gwu.edu> <354D8DBF.F1F79617@rrz.uni-hamburg.de> <980504044259.ZM3556@candle.brasslantern.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"vE7dH2.0.2M5.XvQJr"@math> Resent-From: zsh-users@math.gatech.edu X-Mailing-List: archive/latest/1508 X-Loop: zsh-users@math.gatech.edu X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu 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@rrz.uni-hamburg.de http://www.rrz.uni-hamburg.de/eggink/BEggink.html