zsh-workers
 help / color / mirror / code / Atom feed
* xtrace and redirections
@ 2000-02-04 19:58 Alexandre Duret-Lutz
  2000-02-06 18:24 ` Bart Schaefer
  0 siblings, 1 reply; 2+ messages in thread
From: Alexandre Duret-Lutz @ 2000-02-04 19:58 UTC (permalink / raw)
  To: zsh-workers


Is this already known?

   ~/tmp/tmp % cat bar.zsh
   echo foo > bar 2>&1
   ~/tmp/tmp % zsh -fx bar.zsh
   ~/tmp/tmp % cat bar
   +bar.zsh:1> echo foo
   foo

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.

Other shells do this right:

    ~/tmp/tmp % bash -x bar.zsh
    + echo foo
    ~/tmp/tmp % cat bar
    foo
    ~/tmp/tmp % ksh -x bar.sh
    + echo foo
    + > bar
    + 2>&1
    ~/tmp/tmp % cat bar
    foo

-- 
Alexandre Duret-Lutz


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: xtrace and redirections
  2000-02-04 19:58 xtrace and redirections Alexandre Duret-Lutz
@ 2000-02-06 18:24 ` Bart Schaefer
  0 siblings, 0 replies; 2+ messages in thread
From: Bart Schaefer @ 2000-02-06 18:24 UTC (permalink / raw)
  To: zsh-workers, Alexandre Duret-Lutz

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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2000-02-06 18:25 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-02-04 19:58 xtrace and redirections Alexandre Duret-Lutz
2000-02-06 18:24 ` Bart Schaefer

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).