Jeff King <peff@xxxxxxxx> writes: > I think the method for handling this in the test scripts _is_ worse to > write, understand, and maintain. The problem to me is less that it's > ugly to workaround (which as you note in this case is not great, but not > _too_ bad), but that it's a subtle friction point that may jump up and > bite any test-writer who does something like: > > (foo && bar) 2>stderr Yeah, that is a simple example that clearly shows how removal of BASH_XTRACEFD makes developer's life horrible. > So my view had always been that BASH_XTRACEFD is the good solution, and > if people want to make "-x" work reliably under other shells, then I > won't stop them. But somewhere along the way Gábor did a bunch of fixes > to get things mostly running, and the use of dash with "-x" got added to > CI, so now it's a de facto requirement (if you care about CI > complaining, which we increasingly do). > ... > My vision was that we'd leave BASH_XTRACEFD so people using it could > remain oblivious if they chose, but if the ship has sailed via CI, then > that might have less value. Yeah, that matches my understanding. Unfortunately we cannot easily remove "dash -x" from CI while keeping "dash" without "-x" X-<. Still. I wonder if keeping BASH_XTRACEFD helps developers, when they need to diagnose a new breakage? If their new test fails only in the "dash -x" run but not "bash -x" at the CI, for example?
