Re: [PATCH v3 2/2] test-lib.sh: remove the now-unused "test_untraceable" facility

From: Junio C Hamano <gitster@pobox.com>
To: "SZEDER Gábor" <szeder.dev@gmail.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	git@vger.kernel.org, "Jeff King" <peff@peff.net>,
	"Derrick Stolee" <derrickstolee@github.com>,
	"Taylor Blau" <me@ttaylorr.com>
Subject: Re: [PATCH v3 2/2] test-lib.sh: remove the now-unused "test_untraceable" facility
Date: Mon, 13 Dec 2021 10:51:14 -0800	[thread overview]
Message-ID: <xmqqo85kcp99.fsf@gitster.g> (raw)
In-Reply-To: <20211212201441.GB3400@szeder.dev> ("SZEDER =?utf-8?Q?G=C3=A1?= =?utf-8?Q?bor=22's?= message of "Sun, 12 Dec 2021 21:14:41 +0100")

SZEDER Gábor <szeder.dev@gmail.com> 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@evledraar.gmail.com/?
>
> 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"?