tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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. 


Home | Main Index | Thread Index | Old Index