From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19798 invoked from network); 4 May 1998 16:05:01 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 4 May 1998 16:05:01 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id MAA27107; Mon, 4 May 1998 12:00:10 -0400 (EDT) Resent-Date: Mon, 4 May 1998 11:59:56 -0400 (EDT) From: "Bart Schaefer" Message-Id: <980504085922.ZM4361@candle.brasslantern.com> Date: Mon, 4 May 1998 08:59:22 -0700 In-Reply-To: <354DAE7B.F65FE723@rrz.uni-hamburg.de> Comments: In reply to Bernd Eggink "Re: exit value of intermediate program in pipe" (May 4, 2:03pm) 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> <354DAE7B.F65FE723@rrz.uni-hamburg.de> X-Mailer: Z-Mail (4.0b.820 20aug96) To: Bernd Eggink Subject: Re: exit value of intermediate program in pipe Cc: zsh-users@math.gatech.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"mcApY.0.pc6.yNUJr"@math> Resent-From: zsh-users@math.gatech.edu X-Mailing-List: archive/latest/1510 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, 2:03pm, Bernd Eggink wrote: } Subject: Re: exit value of intermediate program in pipe } } Bart Schaefer wrote: } } > } In ksh, the normal way to kill a coproc is } > } } > } exec 3<&p 3<- } > } > 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! Think about it a moment. If you do cat <&p what happens? The input _of cat_ is connected to the _output_ of the coproc, right? So if you do exec 3<&p then what is descriptor 3? That better be the _output_ of the coproc, too, or ksh is doing some pretty funky special casing. So perhaps you meant to say exec 3>&p 3>- ?? } > 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. OK, then zsh either has a bug or an undocumented feature. If zsh did as ksh does, then zsh's coproc would get EOF as soon as the first thing you redirected to it exited. } > } 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... No, that's not true. Once you've run "coproc g" then you can get "f" to see EOF by simply closing fd 3. It's only the coproc descriptor that gets copied rather than "moved" when you redirect it. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com