PATCH (2 of 2): Re: XTRACE output -- I thought we'd fixed this?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On May 23, 11:16pm, I wrote:
}
} So as nearly as I can tell, the following patch produces a correct
} version of E02xtrace.ztst, including the bug 25145 was intended to
} address.  Any failures this reveals need to be  fixed in the C code.
} For which a proposed patch follows in my next message.

So, here it is, very simple:

Index: Src/exec.c
--- ../current/Src/exec.c	2011-05-23 08:22:44.000000000 -0700
+++ Src/exec.c	2011-05-23 22:38:54.000000000 -0700
@@ -3079,7 +3079,6 @@
 	if (mfds[i] && mfds[i]->ct >= 2)
 	    closemn(mfds, i);
 
-    xtrerr = stderr;
     if (nullexec) {
 	if (nullexec == 1) {
 	    /*
@@ -4260,6 +4259,7 @@
     cmdsp = 0;
     if ((osfc = sfcontext) == SFC_NONE)
 	sfcontext = SFC_DIRECT;
+    xtrerr = stderr;
     doshfunc(shf, args, 0);
     sfcontext = osfc;
     free(cmdstack);

Just wait to restore xtrerr until immediately before entry to the
shell function.  This relies on the fact that nothing else prints
to xtrerr in execcmd() after execshfunc(), but because xtrace-ing
the function call itself happens *inside* execshfunc(), there's
no cleaner way to do this [except to *also* save/restore xtrerr
inside execshfunc(), which would be the paranoid thing to do].

In fact, possibly better is to save/restore xtrerr in doshfunc()
and not change execshfunc() at all.  I both mention this because,
and did not do it because, there are a whole lot of calls to
doshfunc() all over the sources.  It's not clear to me how all
those calls should be xtraced or whether they should [not] be
affected by redirection.

I suspect that the same might also be said of source() as compared
to bin_dot(), if it turns out that "set -x; . file" also has some
bugs.

--