On Wed, Dec 01, 2021 at 03:06:44PM +0100, Ævar Arnfjörð Bjarmason wrote: > I don't really mind keeping BASH_XTRACEFD if it's doing something > useful, but I feel like I'm missing something here. Is it really doing > something useful? > > AFAICT the ony case where it mattered was t1510-repo-setup.sh, which > with my upthread > <patch-1.1-9f735bd0d49-20211129T200950Z-avarab@xxxxxxxxx> now works with > -x, at the trivial cost of skipping a small bi of the test with -x. > > I suppose we could move this BASH_XTRACEFD to tht file in particular if > anyone feel strongly about the trivial loss of tracing that entails. I > figured just skipping it under "-x" and adding a "say" to that effect > was a better trade-off. > > For the rest of the test suite BASH_XTRACEFD effectively didn't matter, > since all our tests had to work under --verbose-log -x anyway under > dash. > > Am I just wrong about this line of thinking, or is it purely that you > two would like to keep BASH_XTRACEFD in case some hypothetical future > caller wants to make use of "test_untraceable=UnfortunatelyYes" again? I don't know that I'd call it purely hypothetical. It was the state for many years in the past. And there has to be per-test hackery to keep it that way. So I wouldn't call XTRACEFD a workaround at all; in my mind it was the solution. Now if people want to do that per-test hackery _also_, because it keeps "-x" more useful for folks who can't or won't use bash, I have no problem with that. What I was hoping to avoid was making it a hard requirement, because now it's one more subtle thing for test writers to have to remember and deal with. But maybe that ship is sailed. If we are running with "-x" and dash in CI, then they're going to see confusing failures there regardless. -Peff
