Re: RFC: Change to the way sh -x works ?

[christos%zoulas.com@localhost (Christos Zoulas)]

On Nov 13,  1:36am, kre%munnari.OZ.AU@localhost (Robert Elz) wrote:
-- Subject: Re: RFC: Change to the way sh -x works ?

| 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?)

Error out, ignore the second?

| 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
| there).
| 
| In a kind of pseudo-code
| 
| 	FILE *stderr. *trace;
| 
| 	/* we are enabling -x */
| 
| 	if (xflag == 1)
| 		return;
| 
| 	if (Xflag)		/* or if !Xflag  - doesn't matter which way is which */
| 		trace = fdopen(dup(fileno(stderr), "...");
| 	else
| 		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...

Right, both would be invalid. 

christos