From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11849 invoked from network); 6 May 1998 11:02:03 -0000 Received: from ns2.primenet.com.au (HELO primenet.com.au) (7795@203.24.36.3) by ns1.primenet.com.au with SMTP; 6 May 1998 11:02:03 -0000 Received: (qmail 7331 invoked from network); 6 May 1998 11:02:00 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns2.primenet.com.au with SMTP; 6 May 1998 11:02:00 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id GAA12629; Wed, 6 May 1998 06:50:25 -0400 (EDT) Resent-Date: Wed, 6 May 1998 06:50:13 -0400 (EDT) Sender: rz2a022@uni-hamburg.de Message-ID: <35503FC1.118B229E@uni-hamburg.de> Date: Wed, 06 May 1998 12:47:29 +0200 From: Bernd Eggink Organization: Regionales Rechenzentrum der Uni Hamburg X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586) MIME-Version: 1.0 To: Bart Schaefer CC: zsh-users@math.gatech.edu Subject: Re: zsh vs. ksh coproc redirection semantics References: <980505100306.ZM9156@candle.brasslantern.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"F3IU43.0.q43.a14Kr"@math> Resent-From: zsh-users@math.gatech.edu X-Mailing-List: archive/latest/1519 X-Loop: zsh-users@math.gatech.edu X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Bart Schaefer wrote: > > On May 5, 1:39pm, Bernd Eggink wrote: > } Subject: Re: exit value of intermediate program in pipe > } > } On Mon, 4 May 1998, Bart Schaefer wrote: > } > } > cat <&p > } > > } > what happens? The input _of cat_ is connected to the _output_ of the > } > coproc, right? > } > } 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. > > So you're saying that in ksh, cat <&p means that the coproc input is > closed and cat takes its input from wherever the coproc was getting its > input? That makes no sense at all. (Which tells me that `exec 3<&p` > must be doing something special in ksh, if indeed it acts as you say.) > > } In ksh 3<&p means "duplicate the coproc input to unit 3". > > I think maybe we're having a cognitive dissonance here. [ ... ] Possibly... I'll try to be more specific: In ksh, 3<&p means "duplicate the input _the coproc is reading from_ to 3". I consider that consistent with the fact that (in ksh as well as in zsh) 3<&0 means "duplicate the input that is currently read from to 3". Of course it doesn't make much sense to copy an input, except for the purpose of closing it. And you must duplicate the coproc input for closing, unless a special syntax is provided for that purpose; you can't say "exec p<&-", because that, of course, would mean something completely different. > } IMHO this is more consistent and intuitive than what zsh does. > > Really? I think having inputs connected to outputs is more intuitive > than having inputs duplicated. In ksh, the connection is done by 'read -p' and 'print -p'. You can't say "print foo >&p" or "read bar <&p", whereas in zsh you can say either "print -p foo" or "print foo >&p". What I meant by "inconsistency" is that in zsh >& and <& mean different things, depending on whether a 'p' or a digit follows. This may be considered a matter of convention, but in effect it prevents you from duplicating the coproc input, and such from closing it (which, if I remember right, was your original problem). As I just noticed, ksh has it's inconsistencies, too. While you can't say "print foo >&p", you can say "exec 4>&p; print foo >&4", and it works. Hm... Reconsidering all that, I think the idea of connecting the coproc's output and input to arbitrary file descriptors would in fact be the most elegant solution. Regards, Bernd -- Bernd Eggink Regionales Rechenzentrum der Uni Hamburg eggink@rrz.uni-hamburg.de http://www.rrz.uni-hamburg.de/eggink/BEggink.html