{"thread":{"id":"61776","subject":"[Test Breakage 2.46.0-rc0] Test t0021.35 fails on NonStop","startedAt":"2024-07-13T16:38:54Z","lastAt":"2024-07-15T19:03:24Z","messageCount":18,"participants":["rsbecker@nexbridge.com","Junio C Hamano","brian m. carlson","Eric Sunshine"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"498635","messageId":"024101dad543$221b4ab0$6651e010$@nexbridge.com","threadId":"61776","inReplyTo":null,"subject":"[Test Breakage 2.46.0-rc0] Test t0021.35 fails on NonStop","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-07-13T16:38:41Z","receivedAt":"2024-07-13T16:38:54Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"Here is the breakage. I included the prior test log in case there was a\ndependency.\n\nchecking prerequisite: TTY\n\nmkdir -p \"$TRASH_DIRECTORY/prereq-test-dir-TTY\" &&\n(\n        cd \"$TRASH_DIRECTORY/prereq-test-dir-TTY\" &&\n        test_have_prereq PERL &&\n\n        # Reading from the pty master seems to get stuck _sometimes_\n        # on Mac OS X 10.5.0, using Perl 5.10.0 or 5.8.9.\n        #\n        # Reproduction recipe: run\n        #\n        #       i=0\n        #       while ./test-terminal.perl echo hi $i\n        #       do\n        #               : $((i = $i + 1))\n        #       done\n        #\n        # After 2000 iterations or so it hangs.\n        # https://rt.cpan.org/Ticket/Display.html?id=65692\n        #\n        test \"$(uname -s)\" != Darwin &&\n\n        perl \"$TEST_DIRECTORY\"/test-terminal.perl \\\n                sh -c \"test -t 1 && test -t 2\"\n\n)\n+ mkdir -p /home/randall/git/t/trash\ndirectory.t0021-conversion/prereq-test-dir-TTY\n+ cd /home/randall/git/t/trash\ndirectory.t0021-conversion/prereq-test-dir-TTY\n+ test_have_prereq PERL\n+ uname -s\n+ test NONSTOP_KERNEL != Darwin\n+ perl /home/randall/git/t/test-terminal.perl sh -c test -t 1 && test -t 2\nCan't locate IO/Pty.pm in @INC (you may need to install the IO::Pty module)\n(@INC contains: /usr/lib/perl5/site_perl/5.30.3/nonstop_kernel\n/usr/lib/perl5/site_perl/5.30.3 /usr/lib/perl5/5.30.3/nonstop_kernel\n/usr/lib/perl5/5.30.3 /usr/lib/perl5/site_perl) at\n/home/randall/git/t/test-terminal.perl line 5.\nBEGIN failed--compilation aborted at /home/randall/git/t/test-terminal.perl\nline 5.\nerror: last command exited with $?=162\nprerequisite TTY not satisfied\nok 34 # skip delayed checkout shows progress by default on tty (pathspec\ncheckout) (missing TTY of PERL,TTY)\n\nexpecting success of 0021.35 'delayed checkout ommits progress on non-tty\n(pathspec checkout)':\n                test_delayed_checkout_progress ! git checkout $opt\n\n+ test_delayed_checkout_progress ! git checkout .\ntest_delayed_checkout_progress: test: argument expected\nerror: last command exited with $?=127\nnot ok 35 - delayed checkout ommits progress on non-tty (pathspec checkout)\n#\n#                       test_delayed_checkout_progress ! git checkout $opt\n#\n1..35\n\n\n--\nBrief whoami: NonStop&UNIX developer since approximately\nUNIX(421664400)\nNonStop(211288444200000000)\n-- In real life, I talk too much.\n\n\n\n"},{"id":"498656","messageId":"xmqq8qy4adl4.fsf@gitster.g","threadId":"61776","inReplyTo":"024101dad543$221b4ab0$6651e010$@nexbridge.com","subject":"Re: [Test Breakage 2.46.0-rc0] Test t0021.35 fails on NonStop","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-14T02:53:43Z","receivedAt":"2024-07-14T02:53:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"<rsbecker@nexbridge.com> writes:\n\n> ok 34 # skip delayed checkout shows progress by default on tty (pathspec\n> checkout) (missing TTY of PERL,TTY)\n>\n> expecting success of 0021.35 'delayed checkout ommits progress on non-tty\n> (pathspec checkout)':\n>                 test_delayed_checkout_progress ! git checkout $opt\n>\n> + test_delayed_checkout_progress ! git checkout .\n> test_delayed_checkout_progress: test: argument expected\n\nThis \"test: argument expected\" is curious.\n\nThe shell function reads like so and it hasn't changed since\n7a132c62 (checkout: make delayed checkout respect --quiet and\n--no-progress, 2021-08-26) introduced it, and there are 3 uses of\n\"test\" builtin function.\n\n        test_delayed_checkout_progress () {\n                if test \"$1\" = \"!\"\n                then\n                        local expect_progress=N &&\n                        shift\n                else\n                        local expect_progress=\n                fi &&\n\n                if test $# -lt 1\n                then\n                        BUG \"no command given to test_delayed_checkout_progress\"\n                fi &&\n\n                (\n                        cd progress &&\n                        GIT_PROGRESS_DELAY=0 &&\n                        export GIT_PROGRESS_DELAY &&\n                        rm -f *.a delay-progress.log &&\n\n                        \"$@\" 2>err &&\n                        grep \"IN: smudge test-delay10.a .* \\\\[DELAYED\\\\]\" delay-progress.log &&\n                        if test \"$expect_progress\" = N\n                        then\n                                ! grep \"Filtering content\" err\n                        else\n                                grep \"Filtering content\" err\n                        fi\n                )\n        }\n\nI do not see how any of these tests can be fed a list of zero or\nmore argument that causes it to barf with \"argument expected\",\nwhen\n\n\ttest_delayed_checkout_progress ! git checkout .\n\nis run.  The first \"are we negated?\" test gets\n\n\ttest \"!\" = \"!\"\n\nand shifts that \"!\" away, the second test that checks the number of\narguments do not need any extra quoting (in other words, $# can never\nbe an empty string, so\n\n\ttest $# -lt 1\n\ncannot become \"test -lt 1\" that would barf, like so:\n\n\t$ ksh -c 'test -lt 1'\n\tksh: test: argument expected\n\nAnd whether expect_progress gets an empty string or N (we should\nhave got N in there, if the shell is so broken that the first\ncomparison between \"!\" and \"!\" were botched and the variable got\nassigned an empty string, or \"local\" were botched and the variable\nwere somehow left uninitialized, expect_progress could be a value\nwe do not expect), the last test to switch between !grep and grep\ncan never break like so:\n\n\t$ ksh -c 'test = N'\n\tksh: test: argument expected\n\nbecause $expect_progress is inside a pair of double quotes.\n\nIn the above \"thinking out aloud\", I invoked ksh because bash and\ndash gives different error messages.\n\nAnother remotely curious thing is that I am not sure how \"local\" in\nthe outer shell influences the use of the variable in the subshell\n(read: now I am speculating if the above code uses some constructs\nthat are so tricky to implement correctly and an unfortunate bug\ngets triggered in your shell), but even if such a bug caused a\nnonsense value to be assigned to $expect_progress, I do not see how\nit can cause \"test\" to barf with \"argument expected\".\n\nSo, I am not sure what is going on at all.\n\nIn any case, this does not sound anything recent.  Do you know that\nthis used to work in previous releases?  Could this be caused by\nchanges in your environment (like which shell is used)?\n"},{"id":"498675","messageId":"001f01dad5f1$e518e6e0$af4ab4a0$@nexbridge.com","threadId":"61776","inReplyTo":"xmqq8qy4adl4.fsf@gitster.g","subject":"RE: [Test Breakage 2.46.0-rc0] Test t0021.35 fails on NonStop","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-07-14T13:29:41Z","receivedAt":"2024-07-14T13:29:49Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Saturday, July 13, 2024 10:54 PM, Junio C Hamano wrote:\n><rsbecker@nexbridge.com> writes:\n>\n>> ok 34 # skip delayed checkout shows progress by default on tty\n>> (pathspec\n>> checkout) (missing TTY of PERL,TTY)\n>>\n>> expecting success of 0021.35 'delayed checkout ommits progress on\n>> non-tty (pathspec checkout)':\n>>                 test_delayed_checkout_progress ! git checkout $opt\n>>\n>> + test_delayed_checkout_progress ! git checkout .\n>> test_delayed_checkout_progress: test: argument expected\n>\n>This \"test: argument expected\" is curious.\n>\n>The shell function reads like so and it hasn't changed since\n>7a132c62 (checkout: make delayed checkout respect --quiet and\n--no-progress,\n>2021-08-26) introduced it, and there are 3 uses of \"test\" builtin function.\n>\n>        test_delayed_checkout_progress () {\n>                if test \"$1\" = \"!\"\n>                then\n>                        local expect_progress=N &&\n>                        shift\n>                else\n>                        local expect_progress=\n>                fi &&\n>\n>                if test $# -lt 1\n>                then\n>                        BUG \"no command given to\ntest_delayed_checkout_progress\"\n>                fi &&\n>\n>                (\n>                        cd progress &&\n>                        GIT_PROGRESS_DELAY=0 &&\n>                        export GIT_PROGRESS_DELAY &&\n>                        rm -f *.a delay-progress.log &&\n>\n>                        \"$@\" 2>err &&\n>                        grep \"IN: smudge test-delay10.a .* \\\\[DELAYED\\\\]\"\ndelay-progress.log\n>&&\n>                        if test \"$expect_progress\" = N\n>                        then\n>                                ! grep \"Filtering content\" err\n>                        else\n>                                grep \"Filtering content\" err\n>                        fi\n>                )\n>        }\n>\n>I do not see how any of these tests can be fed a list of zero or more\nargument that\n>causes it to barf with \"argument expected\", when\n>\n>\ttest_delayed_checkout_progress ! git checkout .\n>\n>is run.  The first \"are we negated?\" test gets\n>\n>\ttest \"!\" = \"!\"\n>\n>and shifts that \"!\" away, the second test that checks the number of\narguments do\n>not need any extra quoting (in other words, $# can never be an empty\nstring, so\n>\n>\ttest $# -lt 1\n>\n>cannot become \"test -lt 1\" that would barf, like so:\n>\n>\t$ ksh -c 'test -lt 1'\n>\tksh: test: argument expected\n>\n>And whether expect_progress gets an empty string or N (we should have got N\nin\n>there, if the shell is so broken that the first comparison between \"!\" and\n\"!\" were\n>botched and the variable got assigned an empty string, or \"local\" were\nbotched and\n>the variable were somehow left uninitialized, expect_progress could be a\nvalue we\n>do not expect), the last test to switch between !grep and grep can never\nbreak like\n>so:\n>\n>\t$ ksh -c 'test = N'\n>\tksh: test: argument expected\n>\n>because $expect_progress is inside a pair of double quotes.\n>\n>In the above \"thinking out aloud\", I invoked ksh because bash and dash\ngives\n>different error messages.\n>\n>Another remotely curious thing is that I am not sure how \"local\" in the\nouter shell\n>influences the use of the variable in the subshell\n>(read: now I am speculating if the above code uses some constructs that are\nso\n>tricky to implement correctly and an unfortunate bug gets triggered in your\nshell),\n>but even if such a bug caused a nonsense value to be assigned to\n$expect_progress,\n>I do not see how it can cause \"test\" to barf with \"argument expected\".\n>\n>So, I am not sure what is going on at all.\n>\n>In any case, this does not sound anything recent.  Do you know that this\nused to\n>work in previous releases?  Could this be caused by changes in your\nenvironment\n>(like which shell is used)?\n\nThis looks like a different between ksh and bash. Under bash, the test\nworks. I can live with that but will have to force bash to be used as the\nshebang #!/bin/sh defaults to ksh on this box.\n\nThanks for looking.\n\n--Randall\n\n"},{"id":"498677","messageId":"002301dad5f5$f6fe3690$e4faa3b0$@nexbridge.com","threadId":"61776","inReplyTo":"xmqq8qy4adl4.fsf@gitster.g","subject":"RE: [Test Breakage 2.46.0-rc0] Test t0021.35 fails on NonStop","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-07-14T13:58:49Z","receivedAt":"2024-07-14T13:58:56Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Saturday, July 13, 2024 10:54 PM, Junio C Hamano wrote:\n><rsbecker@nexbridge.com> writes:\n>\n>> ok 34 # skip delayed checkout shows progress by default on tty\n>> (pathspec\n>> checkout) (missing TTY of PERL,TTY)\n>>\n>> expecting success of 0021.35 'delayed checkout ommits progress on\n>> non-tty (pathspec checkout)':\n>>                 test_delayed_checkout_progress ! git checkout $opt\n>>\n>> + test_delayed_checkout_progress ! git checkout .\n>> test_delayed_checkout_progress: test: argument expected\n>\n>This \"test: argument expected\" is curious.\n>\n>The shell function reads like so and it hasn't changed since\n>7a132c62 (checkout: make delayed checkout respect --quiet and\n--no-progress,\n>2021-08-26) introduced it, and there are 3 uses of \"test\" builtin function.\n>\n>        test_delayed_checkout_progress () {\n>                if test \"$1\" = \"!\"\n>                then\n>                        local expect_progress=N &&\n>                        shift\n>                else\n>                        local expect_progress=\n>                fi &&\n>\n>                if test $# -lt 1\n>                then\n>                        BUG \"no command given to\ntest_delayed_checkout_progress\"\n>                fi &&\n>\n>                (\n>                        cd progress &&\n>                        GIT_PROGRESS_DELAY=0 &&\n>                        export GIT_PROGRESS_DELAY &&\n>                        rm -f *.a delay-progress.log &&\n>\n>                        \"$@\" 2>err &&\n>                        grep \"IN: smudge test-delay10.a .* \\\\[DELAYED\\\\]\"\ndelay-progress.log\n>&&\n>                        if test \"$expect_progress\" = N\n>                        then\n>                                ! grep \"Filtering content\" err\n>                        else\n>                                grep \"Filtering content\" err\n>                        fi\n>                )\n>        }\n>\n>I do not see how any of these tests can be fed a list of zero or more\nargument that\n>causes it to barf with \"argument expected\", when\n>\n>\ttest_delayed_checkout_progress ! git checkout .\n>\n>is run.  The first \"are we negated?\" test gets\n>\n>\ttest \"!\" = \"!\"\n>\n>and shifts that \"!\" away, the second test that checks the number of\narguments do\n>not need any extra quoting (in other words, $# can never be an empty\nstring, so\n>\n>\ttest $# -lt 1\n>\n>cannot become \"test -lt 1\" that would barf, like so:\n>\n>\t$ ksh -c 'test -lt 1'\n>\tksh: test: argument expected\n>\n>And whether expect_progress gets an empty string or N (we should have got N\nin\n>there, if the shell is so broken that the first comparison between \"!\" and\n\"!\" were\n>botched and the variable got assigned an empty string, or \"local\" were\nbotched and\n>the variable were somehow left uninitialized, expect_progress could be a\nvalue we\n>do not expect), the last test to switch between !grep and grep can never\nbreak like\n>so:\n>\n>\t$ ksh -c 'test = N'\n>\tksh: test: argument expected\n>\n>because $expect_progress is inside a pair of double quotes.\n>\n>In the above \"thinking out aloud\", I invoked ksh because bash and dash\ngives\n>different error messages.\n>\n>Another remotely curious thing is that I am not sure how \"local\" in the\nouter shell\n>influences the use of the variable in the subshell\n>(read: now I am speculating if the above code uses some constructs that are\nso\n>tricky to implement correctly and an unfortunate bug gets triggered in your\nshell),\n>but even if such a bug caused a nonsense value to be assigned to\n$expect_progress,\n>I do not see how it can cause \"test\" to barf with \"argument expected\".\n>\n>So, I am not sure what is going on at all.\n>\n>In any case, this does not sound anything recent.  Do you know that this\nused to\n>work in previous releases?  Could this be caused by changes in your\nenvironment\n>(like which shell is used)?\n\nWhat is weird is that this worked fine in previous releases. We did not\nchange operating system versions or shells since...well, this test box was\nbuilt a year ago. The only significant change recently was the TZ variable.\nPrior to that, back last fall was the introduction of IPv6. Other than that,\nthings are pretty stable. What I did add to our CI script just prior to\n2.46.0-rc0 is GIT_TEST_DEFAULT_REF_FORMAT=reftable GIT_TEST_CLONE_2GB=true\nto get the related tests to run. I specifically need to test 2Gb clones\nbecause that is happening a lot on platform.\n\nThe semantics of local in ksh is different than in bash, so it looks like I\nhave to force down the bash path. However, my CI script also runs make test\nwith TEST_LINT= SHELL=/usr/coreutils/bin/bash. My assumption was that this\nwould force bash globally. Apparently that is not the case and ksh is being\nused inside. I don't like having to run the test manually afterwards.\n\n--Randall\n\n\n"},{"id":"498683","messageId":"xmqqttgr9aeb.fsf@gitster.g","threadId":"61776","inReplyTo":"001f01dad5f1$e518e6e0$af4ab4a0$@nexbridge.com","subject":"Re: [Test Breakage 2.46.0-rc0] Test t0021.35 fails on NonStop","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-14T17:00:12Z","receivedAt":"2024-07-14T17:00:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"<rsbecker@nexbridge.com> writes:\n\n> This looks like a different between ksh and bash. Under bash, the test\n> works. I can live with that but will have to force bash to be used as the\n> shebang #!/bin/sh defaults to ksh on this box.\n\nIt turns out that the version of ksh I used in my description does\nnot seem to grok \"local\" at all. I vaguely recall that we've written\noff various hobbist reimplementation of ksh as unusable enough, but\nthis one is ksh93 direct from AT&T Research.\n\nI guess when we said \"as long as we limit our use to a simple 'this\nvariable has visibility limited to the function and its children'\nand nothing else, it is portable enough across practically everybody\nwe care about\", we have written off the real ksh, too.\n\nIn the meantime, we may want to document this in a more prominent\nway.  Perhaps like so:\n\n-------- >8 --------------- >8 --------------- >8 --------\nSubject: doc: guide to use of \"local\" shell language construct\n\nThe scripted Porcelain commands do not allow use of \"local\" because\nit is not universally supported, but we use it liberally in our test\nscripts, which means some POSIX compliant shells (like \"ksh93\") can\nnot be used to run our tests.\n\nDocument the status quo, and hint that we might want to change the\nsituation in the fiture.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n Documentation/CodingGuidelines | 4 +++-\n t/README                       | 8 ++++++++\n 2 files changed, 11 insertions(+), 1 deletion(-)\n\ndiff --git c/Documentation/CodingGuidelines w/Documentation/CodingGuidelines\nindex 1d92b2da03..68b7210f48 100644\n--- c/Documentation/CodingGuidelines\n+++ w/Documentation/CodingGuidelines\n@@ -186,7 +186,9 @@ For shell scripts specifically (not exhaustive):\n  - Even though \"local\" is not part of POSIX, we make heavy use of it\n    in our test suite.  We do not use it in scripted Porcelains, and\n    hopefully nobody starts using \"local\" before they are reimplemented\n-   in C ;-)\n+   in C ;-) Notably, ksh (not just reimplementations but the real one\n+   from AT&T Research) does not support \"local\" and cannot be used,\n+   which we might want to reconsider.\n \n  - Some versions of shell do not understand \"export variable=value\",\n    so we write \"variable=value\" and then \"export variable\" on two\ndiff --git c/t/README w/t/README\nindex d9e0e07506..1d39d8cfd5 100644\n--- c/t/README\n+++ w/t/README\n@@ -850,6 +850,14 @@ And here are the \"don'ts:\"\n    but the best indication is to just run the tests with prove(1),\n    it'll complain if anything is amiss.\n \n+ - Don't overuse \"local\"\n+\n+   Because strictly POSIX-compliant shells do not have to support\n+   \"local\", we avoid using it in our scripted Porcelain scripts, but\n+   we have allowed use of \"local\" in test scripts.  We may want to\n+   reconsider this and rewrite our tests to also run on shells like\n+   ksh93.  Do not add new use of \"local\" unnecessarily.\n+\n \n Skipping tests\n --------------\n"},{"id":"498687","messageId":"003301dad613$62b40aa0$281c1fe0$@nexbridge.com","threadId":"61776","inReplyTo":"xmqqttgr9aeb.fsf@gitster.g","subject":"RE: [Test Breakage 2.46.0-rc0] Test t0021.35 fails on NonStop","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-07-14T17:29:25Z","receivedAt":"2024-07-14T17:29:40Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Sunday, July 14, 2024 1:00 PM, Junio C Hamano wrote:\n><rsbecker@nexbridge.com> writes:\n>\n>> This looks like a different between ksh and bash. Under bash, the test\n>> works. I can live with that but will have to force bash to be used as\n>> the shebang #!/bin/sh defaults to ksh on this box.\n>\n>It turns out that the version of ksh I used in my description does not seem\nto grok\n>\"local\" at all. I vaguely recall that we've written off various hobbist\n>reimplementation of ksh as unusable enough, but this one is ksh93 direct\nfrom\n>AT&T Research.\n>\n>I guess when we said \"as long as we limit our use to a simple 'this\nvariable has\n>visibility limited to the function and its children'\n>and nothing else, it is portable enough across practically everybody we\ncare about\",\n>we have written off the real ksh, too.\n>\n>In the meantime, we may want to document this in a more prominent way.\n>Perhaps like so:\n>\n>-------- >8 --------------- >8 --------------- >8 --------\n>Subject: doc: guide to use of \"local\" shell language construct\n>\n>The scripted Porcelain commands do not allow use of \"local\" because it is\nnot\n>universally supported, but we use it liberally in our test scripts, which\nmeans some\n>POSIX compliant shells (like \"ksh93\") can not be used to run our tests.\n>\n>Document the status quo, and hint that we might want to change the\nsituation in\n>the fiture.\n>\n>Signed-off-by: Junio C Hamano <gitster@pobox.com>\n>---\n> Documentation/CodingGuidelines | 4 +++-\n> t/README                       | 8 ++++++++\n> 2 files changed, 11 insertions(+), 1 deletion(-)\n>\n>diff --git c/Documentation/CodingGuidelines\nw/Documentation/CodingGuidelines\n>index 1d92b2da03..68b7210f48 100644\n>--- c/Documentation/CodingGuidelines\n>+++ w/Documentation/CodingGuidelines\n>@@ -186,7 +186,9 @@ For shell scripts specifically (not exhaustive):\n>  - Even though \"local\" is not part of POSIX, we make heavy use of it\n>    in our test suite.  We do not use it in scripted Porcelains, and\n>    hopefully nobody starts using \"local\" before they are reimplemented\n>-   in C ;-)\n>+   in C ;-) Notably, ksh (not just reimplementations but the real one\n>+   from AT&T Research) does not support \"local\" and cannot be used,\n>+   which we might want to reconsider.\n>\n>  - Some versions of shell do not understand \"export variable=value\",\n>    so we write \"variable=value\" and then \"export variable\" on two diff\n--git\n>c/t/README w/t/README index d9e0e07506..1d39d8cfd5 100644\n>--- c/t/README\n>+++ w/t/README\n>@@ -850,6 +850,14 @@ And here are the \"don'ts:\"\n>    but the best indication is to just run the tests with prove(1),\n>    it'll complain if anything is amiss.\n>\n>+ - Don't overuse \"local\"\n>+\n>+   Because strictly POSIX-compliant shells do not have to support\n>+   \"local\", we avoid using it in our scripted Porcelain scripts, but\n>+   we have allowed use of \"local\" in test scripts.  We may want to\n>+   reconsider this and rewrite our tests to also run on shells like\n>+   ksh93.  Do not add new use of \"local\" unnecessarily.\n>+\n>\n> Skipping tests\n> --------------\n\nThanks. I approve. I'm currently working on trying to get the test suite to\nrun under bash. It looks like TEST_SHELL_PATH is not propagated to the inner\nmake -C test. My current approach is to run the inner make without the outer\nmake. Otherwise I am forced to use ksh, which is known not to work. Will\nadvice when this runs - I have to rebuild, and that takes about an hour.\n\n"},{"id":"498688","messageId":"ZpQVwyVQT8Wf5AeX@tapette.crustytoothpaste.net","threadId":"61776","inReplyTo":"xmqqttgr9aeb.fsf@gitster.g","subject":"Re: [Test Breakage 2.46.0-rc0] Test t0021.35 fails on NonStop","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-07-14T18:15:31Z","receivedAt":"2024-07-14T18:15:39Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-07-14 at 17:00:12, Junio C Hamano wrote:\n> <rsbecker@nexbridge.com> writes:\n> \n> > This looks like a different between ksh and bash. Under bash, the test\n> > works. I can live with that but will have to force bash to be used as the\n> > shebang #!/bin/sh defaults to ksh on this box.\n> \n> It turns out that the version of ksh I used in my description does\n> not seem to grok \"local\" at all. I vaguely recall that we've written\n> off various hobbist reimplementation of ksh as unusable enough, but\n> this one is ksh93 direct from AT&T Research.\n> \n> I guess when we said \"as long as we limit our use to a simple 'this\n> variable has visibility limited to the function and its children'\n> and nothing else, it is portable enough across practically everybody\n> we care about\", we have written off the real ksh, too.\n> \n> In the meantime, we may want to document this in a more prominent\n> way.  Perhaps like so:\n> \n> -------- >8 --------------- >8 --------------- >8 --------\n> Subject: doc: guide to use of \"local\" shell language construct\n> \n> The scripted Porcelain commands do not allow use of \"local\" because\n> it is not universally supported, but we use it liberally in our test\n> scripts, which means some POSIX compliant shells (like \"ksh93\") can\n> not be used to run our tests.\n> \n> Document the status quo, and hint that we might want to change the\n> situation in the fiture.\n\nI don't think this is the right approach.  Every version of ksh _except_\nAT&T ksh works just fine here.  pdksh, mksh, lksh, OpenBSD's ksh (which\nis also its /bin/sh) work fine, as do bash, dash, FreeBSD's sh (ash),\nBusybox's sh (also ash), and zsh (when run in sh mode with 5.9 or\nnewer).  AT&T ksh is considering adding local in a newer version for\nthis reason.\n\nLiterally only AT&T ksh is not supported here, and so anyone can set\nSHELL_PATH to any suitable shell.  I don't think it's useful to get rid\nof local when there are a variety of acceptable and portable options.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"498689","messageId":"004501dad61b$b35b7f30$1a127d90$@nexbridge.com","threadId":"61776","inReplyTo":"ZpQVwyVQT8Wf5AeX@tapette.crustytoothpaste.net","subject":"RE: [Test Breakage 2.46.0-rc0] Test t0021.35 fails on NonStop","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-07-14T18:28:56Z","receivedAt":"2024-07-14T18:29:09Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Sunday, July 14, 2024 2:16 PM, brian m. carlson wrote:\n>To: Junio C Hamano <gitster@pobox.com>\n>Cc: rsbecker@nexbridge.com; git@vger.kernel.org\n>Subject: Re: [Test Breakage 2.46.0-rc0] Test t0021.35 fails on NonStop\n>\n>On 2024-07-14 at 17:00:12, Junio C Hamano wrote:\n>> <rsbecker@nexbridge.com> writes:\n>>\n>> > This looks like a different between ksh and bash. Under bash, the\n>> > test works. I can live with that but will have to force bash to be\n>> > used as the shebang #!/bin/sh defaults to ksh on this box.\n>>\n>> It turns out that the version of ksh I used in my description does not\n>> seem to grok \"local\" at all. I vaguely recall that we've written off\n>> various hobbist reimplementation of ksh as unusable enough, but this\n>> one is ksh93 direct from AT&T Research.\n>>\n>> I guess when we said \"as long as we limit our use to a simple 'this\n>> variable has visibility limited to the function and its children'\n>> and nothing else, it is portable enough across practically everybody\n>> we care about\", we have written off the real ksh, too.\n>>\n>> In the meantime, we may want to document this in a more prominent way.\n>> Perhaps like so:\n>>\n>> -------- >8 --------------- >8 --------------- >8 --------\n>> Subject: doc: guide to use of \"local\" shell language construct\n>>\n>> The scripted Porcelain commands do not allow use of \"local\" because it\n>> is not universally supported, but we use it liberally in our test\n>> scripts, which means some POSIX compliant shells (like \"ksh93\") can\n>> not be used to run our tests.\n>>\n>> Document the status quo, and hint that we might want to change the\n>> situation in the fiture.\n>\n>I don't think this is the right approach.  Every version of ksh _except_ AT&T ksh\n>works just fine here.  pdksh, mksh, lksh, OpenBSD's ksh (which is also its /bin/sh)\n>work fine, as do bash, dash, FreeBSD's sh (ash), Busybox's sh (also ash), and zsh\n>(when run in sh mode with 5.9 or newer).  AT&T ksh is considering adding local in a\n>newer version for this reason.\n>\n>Literally only AT&T ksh is not supported here, and so anyone can set SHELL_PATH to\n>any suitable shell.  I don't think it's useful to get rid of local when there are a variety\n>of acceptable and portable options.\n\nWe can add NonStop's ksh to the list of not supported. I'm using TEST_SHELL_PATH while running make all in the t directory. Test passes when I use bash. For some reason (maybe GNUMake 4.1, which is what I have in my POSIX environment, I don't get TEST_SHELL_PATH passed down from the outer Makefile, but I can work with that. t0021 is now passing in my current CI stream using bash 5.0.18.\n\n--Randall\n\n"},{"id":"498693","messageId":"CAPig+cS9PbV+o_f0EbHPqtG-azHqzu5CpDgB5h+tZ58iGd_B0g@mail.gmail.com","threadId":"61776","inReplyTo":"xmqqttgr9aeb.fsf@gitster.g","subject":"Re: [Test Breakage 2.46.0-rc0] Test t0021.35 fails on NonStop","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2024-07-14T21:27:29Z","receivedAt":"2024-07-14T21:27:42Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sun, Jul 14, 2024 at 1:00 PM Junio C Hamano <gitster@pobox.com> wrote:\n> Subject: doc: guide to use of \"local\" shell language construct\n>\n> The scripted Porcelain commands do not allow use of \"local\" because\n> it is not universally supported, but we use it liberally in our test\n> scripts, which means some POSIX compliant shells (like \"ksh93\") can\n> not be used to run our tests.\n>\n> Document the status quo, and hint that we might want to change the\n> situation in the fiture.\n\ns/fiture/future/\n\n> Signed-off-by: Junio C Hamano <gitster@pobox.com>\n> ---\n> diff --git c/Documentation/CodingGuidelines w/Documentation/CodingGuidelines\n> @@ -186,7 +186,9 @@ For shell scripts specifically (not exhaustive):\n>   - Even though \"local\" is not part of POSIX, we make heavy use of it\n>     in our test suite.  We do not use it in scripted Porcelains, and\n>     hopefully nobody starts using \"local\" before they are reimplemented\n> -   in C ;-)\n> +   in C ;-) Notably, ksh (not just reimplementations but the real one\n> +   from AT&T Research) does not support \"local\" and cannot be used,\n> +   which we might want to reconsider.\n\nThe last bit (\"which we might want to reconsider\") probably belongs in\nthe commit message rather than here in the actual documentation.\nSaying \"we might want to reconsider\" doesn't help people new to the\nproject who are looking for guidance _today_.\n\n> diff --git c/t/README w/t/README\n> @@ -850,6 +850,14 @@ And here are the \"don'ts:\"\n> + - Don't overuse \"local\"\n> +\n> +   Because strictly POSIX-compliant shells do not have to support\n> +   \"local\", we avoid using it in our scripted Porcelain scripts, but\n> +   we have allowed use of \"local\" in test scripts.  We may want to\n> +   reconsider this and rewrite our tests to also run on shells like\n> +   ksh93.  Do not add new use of \"local\" unnecessarily.\n\nSame comment regarding \"We may want to reconsider...\"; it probably\nbelongs in the commit message, not here.\n"},{"id":"498694","messageId":"ZpRKu8Xsz70xNHFp@tapette.crustytoothpaste.net","threadId":"61776","inReplyTo":"004501dad61b$b35b7f30$1a127d90$@nexbridge.com","subject":"Re: [Test Breakage 2.46.0-rc0] Test t0021.35 fails on NonStop","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-07-14T22:01:31Z","receivedAt":"2024-07-14T22:01:34Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-07-14 at 18:28:56, rsbecker@nexbridge.com wrote:\n> On Sunday, July 14, 2024 2:16 PM, brian m. carlson wrote:\n> >I don't think this is the right approach.  Every version of ksh _except_ AT&T ksh\n> >works just fine here.  pdksh, mksh, lksh, OpenBSD's ksh (which is also its /bin/sh)\n> >work fine, as do bash, dash, FreeBSD's sh (ash), Busybox's sh (also ash), and zsh\n> >(when run in sh mode with 5.9 or newer).  AT&T ksh is considering adding local in a\n> >newer version for this reason.\n> >\n> >Literally only AT&T ksh is not supported here, and so anyone can set SHELL_PATH to\n> >any suitable shell.  I don't think it's useful to get rid of local when there are a variety\n> >of acceptable and portable options.\n> \n> We can add NonStop's ksh to the list of not supported. I'm using TEST_SHELL_PATH while running make all in the t directory. Test passes when I use bash. For some reason (maybe GNUMake 4.1, which is what I have in my POSIX environment, I don't get TEST_SHELL_PATH passed down from the outer Makefile, but I can work with that. t0021 is now passing in my current CI stream using bash 5.0.18.\n\nI think we had discussed that you were using AT&T ksh on NonStop, which\nwould explain the situation.  That's the most common version of ksh on\nproprietary Unix systems, and you can usually detect it with something\nlike this:\n\n% ksh -c 'echo $KSH_VERSION'\nVersion AJM 93u+m/1.0.8 2024-01-01\n\nVariants of pdksh look like this (this one from OpenBSD):\n\n% ksh -c 'echo $KSH_VERSION'\n@(#)PD KSH v5.2.14 99/07/13.2\n\nAnd mksh and lksh (which are the same shell, just compiled differently,\nlook like this:\n\n% mksh -c 'echo $KSH_VERSION'\n@(#)MIRBSD KSH R59 2024/02/01 +Debian\n\n% lksh -c 'echo $KSH_VERSION'\n@(#)LEGACY KSH R59 2024/02/01 +Debian\n\nI think using bash as a workaround is the right choice here if all you\nhave is AT&T ksh.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"498695","messageId":"006201dad63b$418c76f0$c4a564d0$@nexbridge.com","threadId":"61776","inReplyTo":"ZpRKu8Xsz70xNHFp@tapette.crustytoothpaste.net","subject":"RE: [Test Breakage 2.46.0-rc0] Test t0021.35 fails on NonStop","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-07-14T22:14:49Z","receivedAt":"2024-07-14T22:15:01Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Sunday, July 14, 2024 6:02 PM, brian m. carlson wrote:\n>On 2024-07-14 at 18:28:56, rsbecker@nexbridge.com wrote:\n>> On Sunday, July 14, 2024 2:16 PM, brian m. carlson wrote:\n>> >I don't think this is the right approach.  Every version of ksh\n>> >_except_ AT&T ksh works just fine here.  pdksh, mksh, lksh, OpenBSD's\n>> >ksh (which is also its /bin/sh) work fine, as do bash, dash,\n>> >FreeBSD's sh (ash), Busybox's sh (also ash), and zsh (when run in sh\n>> >mode with 5.9 or newer).  AT&T ksh is considering adding local in a newer\n>version for this reason.\n>> >\n>> >Literally only AT&T ksh is not supported here, and so anyone can set\n>> >SHELL_PATH to any suitable shell.  I don't think it's useful to get\n>> >rid of local when there are a variety of acceptable and portable options.\n>>\n>> We can add NonStop's ksh to the list of not supported. I'm using\n>TEST_SHELL_PATH while running make all in the t directory. Test passes when I use\n>bash. For some reason (maybe GNUMake 4.1, which is what I have in my POSIX\n>environment, I don't get TEST_SHELL_PATH passed down from the outer Makefile,\n>but I can work with that. t0021 is now passing in my current CI stream using bash\n>5.0.18.\n>\n>I think we had discussed that you were using AT&T ksh on NonStop, which would\n>explain the situation.  That's the most common version of ksh on proprietary Unix\n>systems, and you can usually detect it with something like this:\n>\n>% ksh -c 'echo $KSH_VERSION'\n>Version AJM 93u+m/1.0.8 2024-01-01\n>\n>Variants of pdksh look like this (this one from OpenBSD):\n>\n>% ksh -c 'echo $KSH_VERSION'\n>@(#)PD KSH v5.2.14 99/07/13.2\n>\n>And mksh and lksh (which are the same shell, just compiled differently, look like\n>this:\n>\n>% mksh -c 'echo $KSH_VERSION'\n>@(#)MIRBSD KSH R59 2024/02/01 +Debian\n>\n>% lksh -c 'echo $KSH_VERSION'\n>@(#)LEGACY KSH R59 2024/02/01 +Debian\n>\n>I think using bash as a workaround is the right choice here if all you have is AT&T\n>ksh.\n\nWe did discuss the ksh issue on NonStop but the check for whether this is an AT&T ksh is non-functional (KSH_VERSION is not set). What we did was change SHELL=/usr/coreutils/bin/bash and TEST_LINT= to get the tests to execute. Unfortunately, the GNU Make we have (4.1) does not pass TEST_SHELL_PATH (also set) down to inner make processes, so we still get stuck with ksh. I changed our CI system to run the test make on its own, which is now working on this test.\n\nRegards,\nRandall\n\n"},{"id":"498729","messageId":"xmqq1q3u8zmr.fsf@gitster.g","threadId":"61776","inReplyTo":"ZpQVwyVQT8Wf5AeX@tapette.crustytoothpaste.net","subject":"Re: [Test Breakage 2.46.0-rc0] Test t0021.35 fails on NonStop","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-15T15:05:00Z","receivedAt":"2024-07-15T15:05:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n> I don't think this is the right approach.  Every version of ksh\n> _except_ AT&T ksh works just fine here. ... AT&T ksh is\n> considering adding local in a newer version for this reason.\n\nThanks.  That is nice to know, though unfortunately I didn't see\nsigns of them making much progress.\n\nLet's not make or change any policy but just document what we found\nto help the next person.\n\n------ >8 ----------- >8 ----------- >8 ------\nSubject: [PATCH] doc: note that AT&T ksh does not work with our test suite\n\nThe scripted Porcelain commands do not allow use of \"local\" because\nit is not universally supported, but we use it liberally in our test\nscripts, which means some POSIX compliant shells (like \"ksh93\") can\nnot be used to run our tests.\n\nDocument the status quo, to help the next person who gets perplexed\nseeing our tests fail.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n Documentation/CodingGuidelines | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines\nindex 1d92b2da03..94ca5cf7c0 100644\n--- a/Documentation/CodingGuidelines\n+++ b/Documentation/CodingGuidelines\n@@ -185,8 +185,8 @@ For shell scripts specifically (not exhaustive):\n \n  - Even though \"local\" is not part of POSIX, we make heavy use of it\n    in our test suite.  We do not use it in scripted Porcelains, and\n-   hopefully nobody starts using \"local\" before they are reimplemented\n-   in C ;-)\n+   hopefully nobody starts using \"local\" before all shells that matter\n+   support it (notably, ksh from AT&T Research does not support it yet).\n \n  - Some versions of shell do not understand \"export variable=value\",\n    so we write \"variable=value\" and then \"export variable\" on two\n-- \n2.46.0-rc0-140-g824782812f\n\n"},{"id":"498730","messageId":"xmqqv8167kd8.fsf@gitster.g","threadId":"61776","inReplyTo":"ZpRKu8Xsz70xNHFp@tapette.crustytoothpaste.net","subject":"Re: [Test Breakage 2.46.0-rc0] Test t0021.35 fails on NonStop","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-15T15:20:03Z","receivedAt":"2024-07-15T15:20:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n> I think we had discussed that you were using AT&T ksh on NonStop, which\n> would explain the situation.  That's the most common version of ksh on\n> proprietary Unix systems, and you can usually detect it with something\n> like this:\n\nWhat is sad is that we have this as literally the very first thing\nin our test suite, as t0000.1, but ...\n\n        try_local_xy () {\n                local x=\"local\" y=\"alsolocal\" &&\n                echo \"$x $y\"\n        }\n\n        # Check whether the shell supports the \"local\" keyword. \"local\" is not\n        # POSIX-standard, but it is very widely supported by POSIX-compliant\n        # shells, and we rely on it within Git's test framework.\n        #\n        # If your shell fails this test, the results of other tests may be\n        # unreliable. You may wish to report the problem to the Git mailing\n        # list <git@vger.kernel.org>, as it could cause us to reconsider\n        # relying on \"local\".\n        test_expect_success 'verify that the running shell supports \"local\"' '\n                x=\"notlocal\" &&\n                y=\"alsonotlocal\" &&\n                echo \"local alsolocal\" >expected1 &&\n                try_local_xy >actual1 &&\n                test_cmp expected1 actual1 &&\n                echo \"notlocal alsonotlocal\" >expected2 &&\n                echo \"$x $y\" >actual2 &&\n                test_cmp expected2 actual2\n        '\n\n... apparently it is just like any other test failure, so unless the\ntester is running\n\n\t$ shell t0000-basic.sh -i\n\nreading the output, *AND* goes to the test script to read that\ncomment, the helpful comment can easily be missed.\n\nI am wondering if it is worth doing something like this.\n\n\n t/t0000-basic.sh | 13 ++++++++++++-\n 1 file changed, 12 insertions(+), 1 deletion(-)\n\ndiff --git c/t/t0000-basic.sh w/t/t0000-basic.sh\nindex 98b81e4d63..3cb8243cb4 100755\n--- c/t/t0000-basic.sh\n+++ w/t/t0000-basic.sh\n@@ -34,7 +34,7 @@ try_local_xy () {\n # unreliable. You may wish to report the problem to the Git mailing\n # list <git@vger.kernel.org>, as it could cause us to reconsider\n # relying on \"local\".\n-test_expect_success 'verify that the running shell supports \"local\"' '\n+test_lazy_prereeq WORKING_LOCAL '\n \tx=\"notlocal\" &&\n \ty=\"alsonotlocal\" &&\n \techo \"local alsolocal\" >expected1 &&\n@@ -45,6 +45,17 @@ test_expect_success 'verify that the running shell supports \"local\"' '\n \ttest_cmp expected2 actual2\n '\n \n+if ! test_have_prereq WORKING_LOCAL\n+then\n+\tskip_all='\n+\t\tYour shell has no working \"local\", no tests will work.\n+\t\tYou may wish to report the problem to the Git mailing\n+\t\tlist <git@vger.kernel.org>, unless it is AT&T ksh,\n+\t\twhich we know lacks \"local\".  In the meantime, use\n+\t\tshells that support \"local\", like dash, bash, pdksh...'\n+\ttest_done\n+fi\n+\n ################################################################\n # git init has been done in an empty repository.\n # make sure it is empty.\n"},{"id":"498731","messageId":"00af01dad6cc$41f10d40$c5d327c0$@nexbridge.com","threadId":"61776","inReplyTo":"xmqqv8167kd8.fsf@gitster.g","subject":"RE: [Test Breakage 2.46.0-rc0] Test t0021.35 fails on NonStop","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-07-15T15:32:46Z","receivedAt":"2024-07-15T15:32:59Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Monday, July 15, 2024 11:20 AM, Junio C Hamano wrote:\n>\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n>\n>> I think we had discussed that you were using AT&T ksh on NonStop,\n>> which would explain the situation.  That's the most common version of\n>> ksh on proprietary Unix systems, and you can usually detect it with\n>> something like this:\n>\n>What is sad is that we have this as literally the very first thing in our\ntest suite, as\n>t0000.1, but ...\n>\n>        try_local_xy () {\n>                local x=\"local\" y=\"alsolocal\" &&\n>                echo \"$x $y\"\n>        }\n>\n>        # Check whether the shell supports the \"local\" keyword. \"local\" is\nnot\n>        # POSIX-standard, but it is very widely supported by\nPOSIX-compliant\n>        # shells, and we rely on it within Git's test framework.\n>        #\n>        # If your shell fails this test, the results of other tests may be\n>        # unreliable. You may wish to report the problem to the Git mailing\n>        # list <git@vger.kernel.org>, as it could cause us to reconsider\n>        # relying on \"local\".\n>        test_expect_success 'verify that the running shell supports\n\"local\"' '\n>                x=\"notlocal\" &&\n>                y=\"alsonotlocal\" &&\n>                echo \"local alsolocal\" >expected1 &&\n>                try_local_xy >actual1 &&\n>                test_cmp expected1 actual1 &&\n>                echo \"notlocal alsonotlocal\" >expected2 &&\n>                echo \"$x $y\" >actual2 &&\n>                test_cmp expected2 actual2\n>        '\n>\n>... apparently it is just like any other test failure, so unless the tester\nis running\n>\n>\t$ shell t0000-basic.sh -i\n>\n>reading the output, *AND* goes to the test script to read that comment, the\nhelpful\n>comment can easily be missed.\n>\n>I am wondering if it is worth doing something like this.\n>\n>\n> t/t0000-basic.sh | 13 ++++++++++++-\n> 1 file changed, 12 insertions(+), 1 deletion(-)\n>\n>diff --git c/t/t0000-basic.sh w/t/t0000-basic.sh index\n98b81e4d63..3cb8243cb4\n>100755\n>--- c/t/t0000-basic.sh\n>+++ w/t/t0000-basic.sh\n>@@ -34,7 +34,7 @@ try_local_xy () {\n> # unreliable. You may wish to report the problem to the Git mailing  #\nlist\n><git@vger.kernel.org>, as it could cause us to reconsider  # relying on\n\"local\".\n>-test_expect_success 'verify that the running shell supports \"local\"' '\n>+test_lazy_prereeq WORKING_LOCAL '\n> \tx=\"notlocal\" &&\n> \ty=\"alsonotlocal\" &&\n> \techo \"local alsolocal\" >expected1 &&\n>@@ -45,6 +45,17 @@ test_expect_success 'verify that the running shell\nsupports\n>\"local\"' '\n> \ttest_cmp expected2 actual2\n> '\n>\n>+if ! test_have_prereq WORKING_LOCAL\n>+then\n>+\tskip_all='\n>+\t\tYour shell has no working \"local\", no tests will work.\n>+\t\tYou may wish to report the problem to the Git mailing\n>+\t\tlist <git@vger.kernel.org>, unless it is AT&T ksh,\n>+\t\twhich we know lacks \"local\".  In the meantime, use\n>+\t\tshells that support \"local\", like dash, bash, pdksh...'\n>+\ttest_done\n>+fi\n>+\n> ################################################################\n> # git init has been done in an empty repository.\n> # make sure it is empty.\n\nWhat is strange is that when running on NonStop using ksh, t0000.1 has never\nfailed. I think the situation is subtly different from what we are solving.\nMy take is that there is a difference in the local vs. non-local variable\nset semantic, rather than just accepting the keyword. I would propose that\nwe need a more comprehensive local test to verify the actual expected\nsemantics rather than just testing the syntax.\n\n"},{"id":"498739","messageId":"xmqqh6cq4ngc.fsf@gitster.g","threadId":"61776","inReplyTo":"00af01dad6cc$41f10d40$c5d327c0$@nexbridge.com","subject":"Re: [Test Breakage 2.46.0-rc0] Test t0021.35 fails on NonStop","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-15T16:41:39Z","receivedAt":"2024-07-15T16:41:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"<rsbecker@nexbridge.com> writes:\n\n> What is strange is that when running on NonStop using ksh, t0000.1 has never\n> failed. I think the situation is subtly different from what we are solving.\n> My take is that there is a difference in the local vs. non-local variable\n> set semantic, rather than just accepting the keyword. I would propose that\n> we need a more comprehensive local test to verify the actual expected\n> semantics rather than just testing the syntax.\n\nIt is possible that I may be misreading that first test, but as far\nas I can tell, it is testing not just the syntax but tests how the\nvariables declared \"local\" behaves and should notice if they are not\nlocalized.  It checks that \"local\" assignments in try_local_xy does\ntake effect, and (more importantly) after try_local_xy returns, the\noriginal values are restored.\n\nAs I speculated earlier in an earlier message, the breakage you\nreported may have to do with interaction between \"local\" and use of\na subshell, and perhaps we can also check that pattern in the test.\n\nThanks.\n\n\n"},{"id":"498743","messageId":"00c001dad6dd$f336c3e0$d9a44ba0$@nexbridge.com","threadId":"61776","inReplyTo":"xmqqh6cq4ngc.fsf@gitster.g","subject":"RE: [Test Breakage 2.46.0-rc0] Test t0021.35 fails on NonStop","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-07-15T17:39:25Z","receivedAt":"2024-07-15T17:39:43Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Monday, July 15, 2024 12:42 PM, Junio C Hamano wrote:\n><rsbecker@nexbridge.com> writes:\n>\n>> What is strange is that when running on NonStop using ksh, t0000.1 has\n>> never failed. I think the situation is subtly different from what we are\nsolving.\n>> My take is that there is a difference in the local vs. non-local\n>> variable set semantic, rather than just accepting the keyword. I would\n>> propose that we need a more comprehensive local test to verify the\n>> actual expected semantics rather than just testing the syntax.\n>\n>It is possible that I may be misreading that first test, but as far as I\ncan tell, it is\n>testing not just the syntax but tests how the variables declared \"local\"\nbehaves and\n>should notice if they are not localized.  It checks that \"local\"\nassignments in\n>try_local_xy does take effect, and (more importantly) after try_local_xy\nreturns, the\n>original values are restored.\n>\n>As I speculated earlier in an earlier message, the breakage you reported\nmay have to\n>do with interaction between \"local\" and use of a subshell, and perhaps we\ncan also\n>check that pattern in the test.\n\nThat is that I am also suggesting but did not say it as precisely. Thanks.\n\n"},{"id":"498745","messageId":"xmqqsewa33pc.fsf@gitster.g","threadId":"61776","inReplyTo":"00c001dad6dd$f336c3e0$d9a44ba0$@nexbridge.com","subject":"Re: [Test Breakage 2.46.0-rc0] Test t0021.35 fails on NonStop","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-15T18:33:35Z","receivedAt":"2024-07-15T18:33:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"<rsbecker@nexbridge.com> writes:\n\n>>As I speculated earlier in an earlier message, the breakage you reported\n> may have to\n>>do with interaction between \"local\" and use of a subshell, and perhaps we\n> can also\n>>check that pattern in the test.\n>\n> That is that I am also suggesting but did not say it as precisely. Thanks.\n\nOh, I see.  Are you volunteering to come up with a minimum addition\nto t0000.1 then?\n\nThanks.\n"},{"id":"498749","messageId":"00cb01dad6e9$a73085b0$f5919110$@nexbridge.com","threadId":"61776","inReplyTo":"xmqqsewa33pc.fsf@gitster.g","subject":"RE: [Test Breakage 2.46.0-rc0] Test t0021.35 fails on NonStop","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-07-15T19:03:12Z","receivedAt":"2024-07-15T19:03:24Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Monday, July 15, 2024 2:34 PM, Junio C Hamano wrote:\n><rsbecker@nexbridge.com> writes:\n>\n>>>As I speculated earlier in an earlier message, the breakage you\n>>>reported\n>> may have to\n>>>do with interaction between \"local\" and use of a subshell, and perhaps\n>>>we\n>> can also\n>>>check that pattern in the test.\n>>\n>> That is that I am also suggesting but did not say it as precisely.\nThanks.\n>\n>Oh, I see.  Are you volunteering to come up with a minimum addition to\nt0000.1\n>then?\n\nI'll have to give this some thought on the best way to verify local that\ndoes not break the various other shells. I only have a limited set (ksh,\nbash). Maybe someone with a linux system might be in a better position.\n\n"}]}