RE: [Test Breakage 2.46.0-rc0] Test t0021.35 fails on NonStop

[<rsbecker@nexbridge.com>]

On Monday, July 15, 2024 11:20 AM, Junio C Hamano wrote:
>"brian m. carlson" <sandals@crustytoothpaste.net> writes:
>
>> I think we had discussed that you were using AT&T ksh on NonStop,
>> which would explain the situation.  That's the most common version of
>> ksh on proprietary Unix systems, and you can usually detect it with
>> something like this:
>
>What is sad is that we have this as literally the very first thing in our
test suite, as
>t0000.1, but ...
>
>        try_local_xy () {
>                local x="local" y="alsolocal" &&
>                echo "$x $y"
>        }
>
>        # Check whether the shell supports the "local" keyword. "local" is
not
>        # POSIX-standard, but it is very widely supported by
POSIX-compliant
>        # shells, and we rely on it within Git's test framework.
>        #
>        # If your shell fails this test, the results of other tests may be
>        # unreliable. You may wish to report the problem to the Git mailing
>        # list <git@vger.kernel.org>, as it could cause us to reconsider
>        # relying on "local".
>        test_expect_success 'verify that the running shell supports
"local"' '
>                x="notlocal" &&
>                y="alsonotlocal" &&
>                echo "local alsolocal" >expected1 &&
>                try_local_xy >actual1 &&
>                test_cmp expected1 actual1 &&
>                echo "notlocal alsonotlocal" >expected2 &&
>                echo "$x $y" >actual2 &&
>                test_cmp expected2 actual2
>        '
>
>... apparently it is just like any other test failure, so unless the tester
is running
>
>	$ shell t0000-basic.sh -i
>
>reading the output, *AND* goes to the test script to read that comment, the
helpful
>comment can easily be missed.
>
>I am wondering if it is worth doing something like this.
>
>
> t/t0000-basic.sh | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
>diff --git c/t/t0000-basic.sh w/t/t0000-basic.sh index
98b81e4d63..3cb8243cb4
>100755
>--- c/t/t0000-basic.sh
>+++ w/t/t0000-basic.sh
>@@ -34,7 +34,7 @@ try_local_xy () {
> # unreliable. You may wish to report the problem to the Git mailing  #
list
><git@vger.kernel.org>, as it could cause us to reconsider  # relying on
"local".
>-test_expect_success 'verify that the running shell supports "local"' '
>+test_lazy_prereeq WORKING_LOCAL '
> 	x="notlocal" &&
> 	y="alsonotlocal" &&
> 	echo "local alsolocal" >expected1 &&
>@@ -45,6 +45,17 @@ test_expect_success 'verify that the running shell
supports
>"local"' '
> 	test_cmp expected2 actual2
> '
>
>+if ! test_have_prereq WORKING_LOCAL
>+then
>+	skip_all='
>+		Your shell has no working "local", no tests will work.
>+		You may wish to report the problem to the Git mailing
>+		list <git@vger.kernel.org>, unless it is AT&T ksh,
>+		which we know lacks "local".  In the meantime, use
>+		shells that support "local", like dash, bash, pdksh...'
>+	test_done
>+fi
>+
> ################################################################
> # git init has been done in an empty repository.
> # make sure it is empty.

What is strange is that when running on NonStop using ksh, t0000.1 has never
failed. I think the situation is subtly different from what we are solving.
My take is that there is a difference in the local vs. non-local variable
set semantic, rather than just accepting the keyword. I would propose that
we need a more comprehensive local test to verify the actual expected
semantics rather than just testing the syntax.