From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23834 invoked from network); 5 May 1998 12:05:00 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 5 May 1998 12:05:00 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id HAA18884; Tue, 5 May 1998 07:39:59 -0400 (EDT) Resent-Date: Tue, 5 May 1998 07:39:44 -0400 (EDT) Date: Tue, 5 May 1998 13:39:33 +0200 (DFT) From: Bernd Eggink To: Bart Schaefer cc: Bernd Eggink , zsh-users@math.gatech.edu Subject: Re: exit value of intermediate program in pipe In-Reply-To: <980504085922.ZM4361@candle.brasslantern.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"lhHF72.0.dc4.0glJr"@math> Resent-From: zsh-users@math.gatech.edu X-Mailing-List: archive/latest/1516 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 Mon, 4 May 1998, Bart Schaefer wrote: > 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>- Hm, I admit that I never tried this in zsh... In fact, it works like this in zsh, but exactly the OTHER way round in ksh. In ksh 3<&p means "duplicate the coproc input to unit 3". IMHO this is more consistent and intuitive than what zsh does. After looking into the doc, I even suspect that this may be a bug... Quoting from chapter 6, "redirection": <&p >&p The input/output from/to the coprocess is moved to the standard input/output. If 'input' corresponds to <&p, this is fact what ksh does and what zsh DOESN'T! Regards, Bernd -- Bernd Eggink Regionales Rechenzentrum der Uni Hamburg eggink@rrz.uni-hamburg.de http://www.rrz.uni-hamburg.de/eggink/BEggink.html