Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: exit value of intermediate program in pipe
- X-seq: zsh-users 1516
- From: Bernd Eggink <rz2a022@xxxxxxxxxxxxxx>
- To: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- Subject: Re: exit value of intermediate program in pipe
- Date: Tue, 5 May 1998 13:39:33 +0200 (DFT)
- Cc: Bernd Eggink <eggink@xxxxxxxxxxxxxx>, zsh-users@xxxxxxxxxxxxxxx
- In-reply-to: <980504085922.ZM4361@xxxxxxxxxxxxxxxxxxxxxxx>
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