On Nov 13, 1:36am, k...@munnari.oz.au (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
