From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15998 invoked from network); 4 May 1998 12:11:39 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 4 May 1998 12:11:39 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id HAA21601; Mon, 4 May 1998 07:42:59 -0400 (EDT) Resent-Date: Mon, 4 May 1998 07:42:47 -0400 (EDT) From: "Bart Schaefer" Message-Id: <980504044259.ZM3556@candle.brasslantern.com> Date: Mon, 4 May 1998 04:42:59 -0700 In-Reply-To: <19980504005404.54023@astaroth.nit.gwu.edu> Comments: In reply to Sweth Chandramouli "Re: Re: exit value of intermediate program in pipe" (May 4, 12:54am) 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> In-Reply-To: <354D8DBF.F1F79617@rrz.uni-hamburg.de> Comments: In reply to Bernd Eggink "Re: exit value of intermediate program in pipe" (May 4, 11:43am) X-Mailer: Z-Mail (4.0b.820 20aug96) To: zsh-users@math.gatech.edu Subject: Re: exit value of intermediate program in pipe MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"hNLEO2.0.1H5.tcQJr"@math> Resent-From: zsh-users@math.gatech.edu X-Mailing-List: archive/latest/1507 X-Loop: zsh-users@math.gatech.edu X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On May 4, 12:54am, Sweth Chandramouli wrote: } Subject: Re: Re: exit value of intermediate program in pipe } } the FAQ did have the fact that |& uses the csh syntax, which i had missed, } but has no reference that i could find to >&p or how to use it, and i } think that my (wrong) interpretation was reasonable based on the description } in the manpage. I've already bugged zsh-workers about the manpage deficiency. } as far as i can tell, though, zsh coproc just swallows the eof, since doing } an } echo "^D" >&p } should otherwise have the same effect as "coproc exit", but doesn't. and } _that_ is something that i _would_ consider a bug. No, that's not a bug; ctrl-D only means EOF on tty devices; sending one down any other kind of stream is just sending a byte with the value \004. This isn't DOS where a magic character in any text stream is read as EOF. } > I think { /bin/blah >>(grep -v bar) } is a lot nicer, don't you? } } true, but it still ends when the first process ends No, not quite; it gets EOF when the first process ends, but if it doesn't happen to be a program that exits when it gets EOF on stdin, it'll just keep running. echo goodbye >>(yes hello) produces an unstoppable and rather difficult to kill stream of hellos on your terminal. On some OSs even exiting the tty session many not get rid of it (linux 2.0.x being one of them). } making grep a bg-ed process (or coproc) was } the point of all this, after all, so that wait would recognize it. That ought to be fixed by putting process substitutions in the job table. } the next question would be, how efficient is the coproc? } is it still worth it to go through all of these hoops rather than } just write the output to a temp file? i would imagine so. Probably depends on just how much output we're talking about. The coproc is a pipe, so it doesn't have any filesize limit or quota on its input and output. 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 -- 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. 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? In zsh, I can do coproc cat while true; do echo foo >&p; done & while true; do echo bar >&p; done & cat <&p and get back foo foo foo bar foo bar foo bar bar foo (etc. until killed) 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. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com