From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4235 invoked from network); 6 Feb 2000 18:25:11 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 6 Feb 2000 18:25:11 -0000 Received: (qmail 16737 invoked by alias); 6 Feb 2000 18:24:59 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9586 Received: (qmail 16729 invoked from network); 6 Feb 2000 18:24:57 -0000 From: "Bart Schaefer" Message-Id: <1000206182449.ZM11053@candle.brasslantern.com> Date: Sun, 6 Feb 2000 18:24:49 +0000 In-Reply-To: Comments: In reply to Alexandre Duret-Lutz "xtrace and redirections" (Feb 4, 8:58pm) References: X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk, Alexandre Duret-Lutz Subject: Re: xtrace and redirections MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Feb 4, 8:58pm, Alexandre Duret-Lutz wrote: } Subject: xtrace and redirections } } It looks like the XTRACE output is printed after the IOs } are redirected by the child process. } } This make scripts redirecting stderr fail under zsh -x. This is, in a very round-about way, a side-effect of multios. In order to perform multiple redirections of the same fd correctly, zsh handles command 2>file in almost exactly the same way that it handles ( exec command ) 2>file which, if you try it in another shell, produces just the effect that you see from zsh. (All redirections are treated as if they're outside the parens, not just stderr.) The right fix for this appears to be that zsh should movefd(2) to a SHERR descriptor, the same way it moves fd 0 to SHIN, and then write all xtrace output to SHERR rather than to stderr. However, things get tricky when you have a *real* ( ... ) or { ... } with fd 2 redirected, because in those cases you have to reset SHERR properly in the "fake subshell" too. I don't understand the flow through exec.c well enough to be sure of getting that right. Also, the xtrace code is all over the place, so this is going to be a fairly substantial patch. Does someone else have a more elegant solution? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com