On Monday, July 15, 2024 11:20 AM, Junio C Hamano wrote:
>"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx>, 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@xxxxxxxxxxxxxxx>, 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@xxxxxxxxxxxxxxx>, 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.
