[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: RFC: Change to the way sh -x works ?
Date: Sun, 12 Nov 2017 13:44:25 +0000 (UTC)
From: christos%astron.com@localhost (Christos Zoulas)
| I like it, but I have the same questions as you (should that be a separate
| option -X and what should be the default). I'd say the safe choice is to
| make it a separate option for now.
If I am understanding what you are thinking there, it is not what I meant.
Two different "enable trace" options would be a mess, and wouldn't work
all that well (what do we do if both are enabled?)
The option I intended that could be done would be one to decide whether -x
works as it does now, and follows changes to stderr as they are made, or the
way I proposed, to lock it into stderr as it is when enabled, and keep it
In a kind of pseudo-code
FILE *stderr. *trace;
/* we are enabling -x */
if (xflag == 1)
if (Xflag) /* or if !Xflag - doesn't matter which way is which */
trace = fdopen(dup(fileno(stderr), "...");
trace = stderr;
That doesn't quite do the right thing, as here if stderr changes, trace
would lose track, but the way sh output works, when stderr changes, wjat
is altered is *stderr rather than the pointer
The new option raises all kinds of minor problems, as if implemented
naively, "sh -Xx" would be different than "sh -xX" which would be a bit
hard to explain...
Main Index |
Thread Index |