From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27780 invoked from network); 7 May 1998 09:26:31 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 7 May 1998 09:26:31 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id FAA10059; Thu, 7 May 1998 05:18:20 -0400 (EDT) Resent-Date: Thu, 7 May 1998 05:18:09 -0400 (EDT) From: "Bart Schaefer" Message-Id: <980507021807.ZM16856@candle.brasslantern.com> Date: Thu, 7 May 1998 02:18:06 -0700 In-Reply-To: <199805070717.CAA02705@hzoli.home> Comments: In reply to Zoltan Hidvegi "Re: zsh vs. ksh coproc redirection semantics" (May 7, 2:17am) References: <199805070717.CAA02705@hzoli.home> X-Mailer: Z-Mail (4.0b.820 20aug96) To: Zoltan Hidvegi Subject: Re: zsh vs. ksh coproc redirection semantics Cc: zsh-users@math.gatech.edu MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by math.gatech.edu id FAA10014 Resent-Message-ID: <"e09U13.0.eS2.HnNKr"@math> Resent-From: zsh-users@math.gatech.edu X-Mailing-List: archive/latest/1523 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 7, 2:17am, Zoltan Hidvegi wrote: } Subject: Re: zsh vs. ksh coproc redirection semantics } } Let me quote the ksh manual: } } <&digit- The file descriptor given by digit is moved } to standard input. Similarly for the stan­ } dard output using >&digit-. } } <&- The standard input is closed. Similarly for } the standard output using >&-. I'm curious. In zsh and bash (which also lacks the <&digit- form), <&- closes the standard input of whatever command it suffixes, not of the shell itself. Which must mean that (semantically, if not in actual implementation) stdin is first dup'd (as it always is when running a new command) and then the dup is closed. Is that what happens in ksh? Is that what happens to fd `digit' in the <&digit- form in ksh? I.e., does `digit' actually go away for good only upon `exec <&digit-` ? If not, does cat <&0- close the shell's standard input (leaving it connected to cat)? If so, all I can say is, ick. Yet, if you take `p' to be shorthand for "the digit that is connected to the coproc, followed by `-'" then that's the behavior of } <&p The input from the co-process is moved to } standard input. } } >&p The output to the co-process is moved to } standard output. which seems like yet another potential inconsistency that zsh might be better off not having. Incidentally, that documentation matches what zsh does much closer than it matches what Bernd Eggink described ksh as doing. According to that excerpt, `exec 3<&p 3<&-` should have no effect on the input _of_ the coprocess. } Bart wrote: } > 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'm not sure I understand what you mean here. Looks like you are } confused about terms. No, I know all that stuff about pipes. I was trying to express concepts that it seemed ksh wanted those redirections to embody, rather than the way it has to be implemented underneath. But now that I see the doc, I think Bernd's description was of a ksh that got its own implementation wrong, which is why my attempt to explain it doesn't work either. } About the job table: ksh places the coprocess to the job table similarily } to zsh. You can bring the coprocess to the foregroung with fg, which } does not makes much sense, but works. Probably fg followed by ctrl-C is a common kill-the-coproc technique. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com