SZEDER Gábor <szeder.dev@xxxxxxxxx> writes: >> > Please do not remove BASH_XTRACEFD. And especially not like this, >> > without even mentioning it in the commit message. >> >> I can re-roll with an amended commit message that explicitly mentions >> it > > It should rather be a separate patch... > >>, but that doesn't address your "please do not remove", >> >> Do you see reason to keep it at the end-state fo this series? E.g. a >> counter-argument to >> https://lore.kernel.org/git/211210.86pmq4daxm.gmgdl@xxxxxxxxxxxxxxxxxxx/? > > I don't see any argument pertinent to BASH_XTRACEFD in general in that > email, of in favor of its removal in particular, and there are no > valid arguments for its removal in earlier emails in this thread > either. If I am reading Ævar right, the argument is "dash would not be fixed with BASH_XTRACEFD, so there needs another way that would work there, and if the approach happens to work also for bash, then there is no reason to use BASH_XTRACEFD", I think. Now, if the way Ævar came up with to help shells with "-x" not to contaminate their standard error stream that our test scripts want to inspect is worse to write, understand, and maintain, compared to the way we have been writing our tests that inspect their standard errors, without having to worry about "-x" output thanks to the use of BASH_XTRACEFD, it may make a regression to developer productivity, but I am not sure if that is the case. I think [1/2] of this same series can serve an example of how tests must be tweaked to live under the world order without BASH_XTRACEFD? Having to set and use a temporary file to capture the standard error output and append to it upfront looks uglier than each individual test locally capturing the standard error output from a single invocation of a helper function, but it does not look _too_ bad to me. Can we find another example to argue for BASH_XTRACEFD, how much it makes it easier to write tests that work even under "-x"?
