From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3397 invoked from network); 5 Feb 1997 15:28:28 -0000 Received: from euclid.skiles.gatech.edu (list@130.207.146.50) by coral.primenet.com.au with SMTP; 5 Feb 1997 15:28:28 -0000 Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id KAA17246; Wed, 5 Feb 1997 10:04:39 -0500 (EST) Resent-Date: Wed, 5 Feb 1997 10:04:39 -0500 (EST) Message-Id: <199702051506.QAA08836@hydra.ifh.de> To: zsh-workers@math.gatech.edu (Zsh hackers list), Daniel Dignam Subject: Re: set -vx changes output of subshells In-reply-to: "Daniel Dignam"'s message of "Tue, 28 Jan 1997 08:37:32 MET." <32EDBACC.41C6@UG.EDS.COM> Date: Wed, 05 Feb 1997 16:06:26 +0100 From: Peter Stephenson Resent-Message-ID: <"svyXF.0.PD4.76A-o"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/2876 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Daniel Dignam wrote: > Hi Folks, > > I've just built zsh 3.1.1 and have found a problem with redirection in > subshells and set -vx. It appears to be adding a return at the start of > the output (this makes debugging a trifle hard): > > alfep3% set -vx > alfep3% a=$(ls foo 2>&1) > a=$(ls foo 2>&1) > + a=+ a=+ ls foo > foo > alfep3% echo $a | wc -l > echo $a | wc -l > + echo + a=+ ls foo > foo > + wc -l > 2 I got a chance to think about this (didn't notice any other replies) and it's not really clear to me it's a bug. (Sorry, I know that answer grates on the nerves.) You've told zsh to send a message of what it's doing to stderr, then you've redirected stderr from $(...) to the output... naturally the xtrace output goes to the variable so that a contains an initial line `+ a=+ ls -F -l zsh'. Ksh does something different: looking at the output, it seems to be because the 2>&1 doesn't get processed till last, but I can't see a good reason why the shell should *have* to do that. It could probably be moved further up in zsh, removing the doubled xtrace code for builtins and external commands, though it looks like the addvars() part would still have to be separate. This would presumably fix this problem. There are certainly still minor problems with set -x, though: for example, the 2>&1 doesn't appear at all. Probably something needs to be added to addfd(). I noticed one other thing with the option handling: the EXECOPT option, properly the noexec option except it's negated, seems to be doing rather to much work: it does all the forking and I/O redirection even though it doesn't actually execute the commands. So, for example, a script containing: print this is a file >shfile set -n print this is no longer a file >shfile in ksh will leave shfile containing `this is a file', in zsh will leave an empty shfile, since the redirection has been done for the second print even though the command wasn't executed. This is presumably wrong, but how little should noexec be doing? Can we omit the fork in execcmd()? Should the glob then be done without a fork even if the command not to be executed had a & after it? -- Peter Stephenson Tel: +49 33762 77366 WWW: http://www.ifh.de/~pws/ Fax: +49 33762 77413 Deutsches Elektronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen DESY-IfH, 15735 Zeuthen, Germany.