Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: exit value of intermediate program in pipe



Date: Tue, 5 May 1998 13:39:33 +0200 (DFT)
From: Bernd Eggink <rz2a022@xxxxxxxxxxxxxx>
To: zsh-users@xxxxxxxxxxxxxxx
Subject: Re: exit value of intermediate program in pipe

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@xxxxxxxxxxxxxxxxxx
http://www.rrz.uni-hamburg.de/eggink/BEggink.html




Messages sorted by: Reverse Date, Date, Thread, Author