From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16285 invoked from network); 6 May 1998 16:12:12 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 6 May 1998 16:12:12 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id MAA18570; Wed, 6 May 1998 12:01:19 -0400 (EDT) Resent-Date: Wed, 6 May 1998 12:01:02 -0400 (EDT) From: "Bart Schaefer" Message-Id: <980506090047.ZM13585@candle.brasslantern.com> Date: Wed, 6 May 1998 09:00:47 -0700 In-Reply-To: <35503FC1.118B229E@uni-hamburg.de> Comments: In reply to Bernd Eggink "Re: zsh vs. ksh coproc redirection semantics" (May 6, 12:47pm) References: <980505100306.ZM9156@candle.brasslantern.com> <35503FC1.118B229E@uni-hamburg.de> X-Mailer: Z-Mail (4.0b.820 20aug96) To: Bernd Eggink , zsh-users@math.gatech.edu Subject: Re: zsh vs. ksh coproc redirection semantics MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"Ari_v1.0.HX4.za8Kr"@math> Resent-From: zsh-users@math.gatech.edu X-Mailing-List: archive/latest/1520 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 6, 12:47pm, Bernd Eggink wrote: } Subject: Re: zsh vs. ksh coproc redirection semantics } } 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". } [...] } 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. No, that's not true. 3>&1 means to copy the shell's standard output to descriptor 3. 3>&p means copy the shell's coproc output to descriptor 3. 3<&0 means copy the shell's standard input to 3. 3<&p means copy the shell's coproc input to 3 (not move the coproc's input to 3). Ksh, on the other hand, appears to treat <&p as "the coproc end of the two-way pipe" and >&p as "the ksh end of the two-way pipe". This isn't the same as other descriptors, but then other descriptors aren't pipes. I think zsh's treatment ends up working a bit more consistently, because you can always think of descriptor behavior in terms of where the current shell will get or put data. } 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). I still think (based on what you've said in previous messages) that this particular detail is not very consistent in ksh. In zsh, if I do exec 4<&0 exec 4<&- then that closes only descriptor 4, not descriptor 0. Why should exec 3<&p exec 3<&- close both 3 and p? In ksh, if you do exec 4>&p can you later do exec 5>&p and end up having both 4 and 5 connected to the coproc pipe at the same time? My guess is that you can't -- that once you've done 4>&p, then p is gone and you can't do 5>&p. Now, the question is, whether this particular inconsistency with p and other fds is useful enough to emulate it. (Is anybody on zsh-workers reading this? Zefram, Zoltan, Peter?) } 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. I still think that's completely independent. It doesn't matter what descriptors you can connect it to without some kind of special handling to close the original descriptor at the same time that you close the one you connected it to. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com