From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12025 invoked from network); 4 May 1998 04:59:23 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 4 May 1998 04:59:23 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id AAA18027; Mon, 4 May 1998 00:52:40 -0400 (EDT) Resent-Date: Mon, 4 May 1998 00:52:30 -0400 (EDT) Message-ID: <19980504005404.54023@astaroth.nit.gwu.edu> Date: Mon, 4 May 1998 00:54:04 -0400 From: Sweth Chandramouli To: zsh-users@math.gatech.edu Subject: Re: Re: exit value of intermediate program in pipe Mail-Followup-To: zsh-users@math.gatech.edu 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89 In-Reply-To: <980503183549.ZM1342@candle.brasslantern.com> Resent-Message-ID: <"Adkb03.0.AP4.DcKJr"@math> Resent-From: zsh-users@math.gatech.edu X-Mailing-List: archive/latest/1505 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 Sun, May 03, 1998 at 06:35:49PM -0700, Bart Schaefer wrote: [snip] > That line doesn't do what you think. What you'd want is just [snip] > That's not right either. You'd probably need [snip] that's what i was talking about with the need for more examples; 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. > 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. So the grep > won't get EOF when blah exits. You have to shut it down some other way; > the only thing I've found is to start another coprocess. I don't know > if this is a bug, or what. at first, i wasn't sure if this would be a bug or not; it would make some conceptual sense to have a "coprocess exit" command that closed out a coprocess, and when i tried to find some docs on coproc, all i could find was the fmli coproc, which uses a similar cocreate/codestroy metaphor. 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. > So you get > > { > coproc grep -v bar > cat <&p & > /bin/blah >&p > exitstatus=$? > coproc exit # Shuts down grep by closing its input, as > # a side-effect of starting a new coproc > # which then immediately exits. Ewww. does this mean that you can only have one coproc open at a time? i could see situations where it might be useful to have more than one coproc open at once, rather than opening and closing the same two executables over and over in rapid succession. > wait # Allows cat to finish, just in case. > return $exitstatus > } > > I think { /bin/blah >>(grep -v bar) } is a lot nicer, don't you? true, but it still ends when the first process ends, which could cause problems if the other process were something other than a grep, right? making grep a bg-ed process (or coproc) was the point of all this, after all, so that wait would recognize it. 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. -- sweth. -- "Countin' on a remedy I've counted on before Goin' with a cure that's never failed me What you call the disease I call the remedy" -- The Mighty Mighty Bosstones