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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 12 Nov 2017 13:44:25 +0000 (UTC)
    From:        christos%astron.com@localhost (Christos Zoulas)
    Message-ID:  <ou9j7p$57e$1%blaine.gmane.org@localhost>

  | 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
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...

kre