{"thread":{"id":"55609","subject":"[PATCH] CodingGuidelines: explicitly allow \"local\" for test scripts","startedAt":"2021-05-03T04:11:01Z","lastAt":"2021-05-05T17:46:25Z","messageCount":17,"participants":["Junio C Hamano","Eric Sunshine","Ævar Arnfjörð Bjarmason","Felipe Contreras","brian m. carlson","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"423459","messageId":"xmqqfsz4a23x.fsf@gitster.g","threadId":"55609","inReplyTo":null,"subject":"[PATCH] CodingGuidelines: explicitly allow \"local\" for test scripts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-03T04:10:58Z","receivedAt":"2021-05-03T04:11:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"01d3a526 (t0000: check whether the shell supports the \"local\"\nkeyword, 2017-10-26) raised a test balloon to see if those who build\nand test Git use a platform without a shell that lacks support for\nthe \"local\" keyword.  After two years, 7f0b5908 (t0000: reword\ncomments for \"local\" test, 2019-08-08) documented that \"local\"\nkeyword, even though is outside POSIX, is allowed in our test\nscripts.\n\nLet's write it in the CodingGuidelines, too.  It might be tempting\nto allow it in scripted Porcelains (we have avoided getting them\ncontaminiated by \"local\" so far), but they are on their way out and\ngetting rewritten in C.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n Documentation/CodingGuidelines | 5 +++++\n 1 file changed, 5 insertions(+)\n\ndiff --git c/Documentation/CodingGuidelines w/Documentation/CodingGuidelines\nindex 45465bc0c9..ea70676a30 100644\n--- c/Documentation/CodingGuidelines\n+++ w/Documentation/CodingGuidelines\n@@ -175,6 +175,11 @@ For shell scripts specifically (not exhaustive):\n \n    does not have such a problem.\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+\n \n For C programs:\n \n"},{"id":"423460","messageId":"CAPig+cR19WDY1=qTbJMCzxeXjV4XtEddS1+=H8Cj6NUi5ZdN+w@mail.gmail.com","threadId":"55609","inReplyTo":"xmqqfsz4a23x.fsf@gitster.g","subject":"Re: [PATCH] CodingGuidelines: explicitly allow \"local\" for test scripts","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2021-05-03T04:21:28Z","receivedAt":"2021-05-03T04:21:41Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Mon, May 3, 2021 at 12:11 AM Junio C Hamano <gitster@pobox.com> wrote:\n> 01d3a526 (t0000: check whether the shell supports the \"local\"\n> keyword, 2017-10-26) raised a test balloon to see if those who build\n> and test Git use a platform without a shell that lacks support for\n> the \"local\" keyword. [...]\n\nDouble negative whammy. Should be either:\n\n    use a platform with a shell that lacks support\n\nor:\n\n    use a platform without a shell supporting \"local\"\n\nOr I'm confused and misunderstanding what was written.\n"},{"id":"423464","messageId":"xmqqsg348k9j.fsf@gitster.g","threadId":"55609","inReplyTo":"CAPig+cR19WDY1=qTbJMCzxeXjV4XtEddS1+=H8Cj6NUi5ZdN+w@mail.gmail.com","subject":"Re: [PATCH] CodingGuidelines: explicitly allow \"local\" for test scripts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-03T05:21:44Z","receivedAt":"2021-05-03T05:21:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine <sunshine@sunshineco.com> writes:\n\n> Double negative whammy. Should be either:\n>\n>     use a platform with a shell that lacks support\n>\n> or:\n>\n>     use a platform without a shell supporting \"local\"\n>\n> Or I'm confused and misunderstanding what was written.\n\nNo, I just wasn't paying much attention to what I was writing X-<.\nThanks for spotting.\n"},{"id":"423465","messageId":"xmqqo8ds8k6r.fsf_-_@gitster.g","threadId":"55609","inReplyTo":"xmqqsg348k9j.fsf@gitster.g","subject":"[PATCH v2] CodingGuidelines: explicitly allow \"local\" for test scripts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-03T05:23:24Z","receivedAt":"2021-05-03T05:23:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"01d3a526 (t0000: check whether the shell supports the \"local\"\nkeyword, 2017-10-26) raised a test balloon to see if those who build\nand test Git use a platform with a shell that lacks support for the\n\"local\" keyword.  After two years, 7f0b5908 (t0000: reword comments\nfor \"local\" test, 2019-08-08) documented that \"local\" keyword, even\nthough is outside POSIX, is allowed in our test scripts.\n\nLet's write it in the CodingGuidelines, too.  It might be tempting\nto allow it in scripted Porcelains (we have avoided getting them\ncontaminiated by \"local\" so far), but they are on their way out and\ngetting rewritten in C.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n Documentation/CodingGuidelines | 5 +++++\n 1 file changed, 5 insertions(+)\n\ndiff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines\nindex 45465bc0c9..ea70676a30 100644\n--- a/Documentation/CodingGuidelines\n+++ b/Documentation/CodingGuidelines\n@@ -175,6 +175,11 @@ For shell scripts specifically (not exhaustive):\n \n    does not have such a problem.\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+\n \n For C programs:\n \n-- \n2.31.1-579-ge1192275af\n\n"},{"id":"423472","messageId":"877dkgxk9p.fsf@evledraar.gmail.com","threadId":"55609","inReplyTo":"xmqqo8ds8k6r.fsf_-_@gitster.g","subject":"Re: [PATCH v2] CodingGuidelines: explicitly allow \"local\" for test scripts","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-05-03T09:01:27Z","receivedAt":"2021-05-03T09:02:34Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, May 03 2021, Junio C Hamano wrote:\n\n> 01d3a526 (t0000: check whether the shell supports the \"local\"\n> keyword, 2017-10-26) raised a test balloon to see if those who build\n> and test Git use a platform with a shell that lacks support for the\n> \"local\" keyword.  After two years, 7f0b5908 (t0000: reword comments\n> for \"local\" test, 2019-08-08) documented that \"local\" keyword, even\n> though is outside POSIX, is allowed in our test scripts.\n>\n> Let's write it in the CodingGuidelines, too.  It might be tempting\n> to allow it in scripted Porcelains (we have avoided getting them\n> contaminiated by \"local\" so far), but they are on their way out and\n> getting rewritten in C.\n>\n> Signed-off-by: Junio C Hamano <gitster@pobox.com>\n> ---\n>  Documentation/CodingGuidelines | 5 +++++\n>  1 file changed, 5 insertions(+)\n>\n> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines\n> index 45465bc0c9..ea70676a30 100644\n> --- a/Documentation/CodingGuidelines\n> +++ b/Documentation/CodingGuidelines\n> @@ -175,6 +175,11 @@ For shell scripts specifically (not exhaustive):\n>  \n>     does not have such a problem.\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> +\n\nIs there any portability reason to avoid \"local\" in the porcelains? I\ndon't have any plans for using it, but I don't see why we'd explicitly\nforbid it.\n"},{"id":"423559","messageId":"xmqqpmy76w31.fsf@gitster.g","threadId":"55609","inReplyTo":"877dkgxk9p.fsf@evledraar.gmail.com","subject":"Re: [PATCH v2] CodingGuidelines: explicitly allow \"local\" for test scripts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-04T03:01:38Z","receivedAt":"2021-05-04T03:01:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> Is there any portability reason to avoid \"local\" in the porcelains? I\n> don't have any plans for using it, but I don't see why we'd explicitly\n> forbid it.\n\nThings that are not even in POSIX are forbidden unless explicitly\nallowed.\n\nIn general, he way we encouraged people to think has been \"don't use\nit, it is not even in POSIX\" and \"even if it is in POSIX, we know\nthe support by platform/implementation X is broken, so let's not use\nit\".  It has been successfully helped us to stay out of portability\ntroubles.\n\nThere may be a few tiny cases where we said \"practically everybody\nwe care about has it, even though it is not in POSIX, and it makes\nour life so vastly be better\" to explicitly allow some feature,\nthough.\n\nAnd \"local\"?  Not absolutely essential, unless you are doing a\nlibrary that you want to avoid stepping on users' toes.  Besides, we\nare no longer adding scripted Porcelains left and right---rather,\npeople are actively rewriting them.\n\nThanks.\n"},{"id":"423572","messageId":"87czu6wuf3.fsf@evledraar.gmail.com","threadId":"55609","inReplyTo":"xmqqpmy76w31.fsf@gitster.g","subject":"Re: [PATCH v2] CodingGuidelines: explicitly allow \"local\" for test scripts","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-05-04T12:27:24Z","receivedAt":"2021-05-04T12:33:14Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, May 04 2021, Junio C Hamano wrote:\n\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>\n>> Is there any portability reason to avoid \"local\" in the porcelains? I\n>> don't have any plans for using it, but I don't see why we'd explicitly\n>> forbid it.\n>\n> Things that are not even in POSIX are forbidden unless explicitly\n> allowed.\n>\n> In general, he way we encouraged people to think has been \"don't use\n> it, it is not even in POSIX\" and \"even if it is in POSIX, we know\n> the support by platform/implementation X is broken, so let's not use\n> it\".  It has been successfully helped us to stay out of portability\n> troubles.\n>\n> There may be a few tiny cases where we said \"practically everybody\n> we care about has it, even though it is not in POSIX, and it makes\n> our life so vastly be better\" to explicitly allow some feature,\n> though.\n>\n> And \"local\"?  Not absolutely essential, unless you are doing a\n> library that you want to avoid stepping on users' toes.  Besides, we\n> are no longer adding scripted Porcelains left and right---rather,\n> people are actively rewriting them.\n\n[You mailed me off-list with \"Did I forget to say it is not even\nPOSIX?\", I had this reply to that, also applicable here]:\n\nBEGIN QUOTE\n\nI'm aware that it's not in POSIX. What I'm getting at is that anyone who\ndoesn't support this must have been failing t0000-basic.sh since\n01d3a526ad9 (t0000: check whether the shell supports the \"local\"\nkeyword, 2017-10-26), released with v2.16.0.\n\nAnd all tests of any kind since 78dc08875cd (test-lib: allow short\noptions to be bundled, 2020-03-22), perhaps earlier, I didn't trace the\nfull includes, but that's the first use in test-lib.sh itself. Released\nwith v2.27.0.\n\nFrom my own cross-platform testing and us not having any reports about\nthis I very much suspect that this is one of those not-in-POSIX but in\npractice supported everywhere, or at least anywhere Git has been ported\nto.\n\nSo just saying it's OK to use unconditionally of \"in t/?\" should be\nfine, like e.g. some of the C89-plus-XYZ features.\n\nEND QUOTE\n\nAfterwards it occurred to me that your stance on in-tree *.sh goes\nagainst e.g. brian's opinion on it expressed in reply to [1], i.e. that\nwe might justify future new *.sh built-ins.\n\nIn any case, as noted above I really don't care much about using \"local\"\nin any *.sh built-in. I just don't think this \"We do not use it in\nscripted Porcelains[...]\" clause is needed at all.\n\nIt's effectively synonymous with saying \"we still want to support git on\nplatforms that are so broken they can't even run a single test in our\ntest suite\".\n\n1. https://lore.kernel.org/git/patch-1.1-83266f30b67-20210417T084346Z-avarab@gmail.com/\n"},{"id":"423574","messageId":"xmqq7dke7jeo.fsf@gitster.g","threadId":"55609","inReplyTo":"87czu6wuf3.fsf@evledraar.gmail.com","subject":"Re: [PATCH v2] CodingGuidelines: explicitly allow \"local\" for test scripts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-04T12:50:07Z","receivedAt":"2021-05-04T12:50:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> It's effectively synonymous with saying \"we still want to support git on\n> platforms that are so broken they can't even run a single test in our\n> test suite\".\n\nNot really.  Those on such a platform would (rightly) say that it is\nthe test suite that is broken and out of compliance.\n"},{"id":"423579","messageId":"87a6pawmyu.fsf@evledraar.gmail.com","threadId":"55609","inReplyTo":"xmqq7dke7jeo.fsf@gitster.g","subject":"Re: [PATCH v2] CodingGuidelines: explicitly allow \"local\" for test scripts","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-05-04T15:09:54Z","receivedAt":"2021-05-04T15:14:06Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, May 04 2021, Junio C Hamano wrote:\n\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>\n>> It's effectively synonymous with saying \"we still want to support git on\n>> platforms that are so broken they can't even run a single test in our\n>> test suite\".\n>\n> Not really.  Those on such a platform would (rightly) say that it is\n> the test suite that is broken and out of compliance.\n\nIndeed. But the lack of any reports about that suggests that in practice\nthis is universally supported enough to be a hard dependency.\n\nIn any case, it's clear you don't agree and you manage the patch\nqueue. So I'll leave it at that.\n\nMy aim here was to discover if we had any reason to think that \"local\"\nwas less universally implemented than other POSIX/C89-plus features we\nrely on. It seems that it's not.\n"},{"id":"423607","messageId":"6091ad06cecb0_b34a8208bf@natae.notmuch","threadId":"55609","inReplyTo":"87a6pawmyu.fsf@evledraar.gmail.com","subject":"Re: [PATCH v2] CodingGuidelines: explicitly allow \"local\" for test scripts","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-04T20:22:30Z","receivedAt":"2021-05-04T20:22:38Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> On Tue, May 04 2021, Junio C Hamano wrote:\n> > Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n> >\n> >> It's effectively synonymous with saying \"we still want to support git on\n> >> platforms that are so broken they can't even run a single test in our\n> >> test suite\".\n> >\n> > Not really.  Those on such a platform would (rightly) say that it is\n> > the test suite that is broken and out of compliance.\n> \n> Indeed. But the lack of any reports about that suggests that in practice\n> this is universally supported enough to be a hard dependency.\n\nIt is universally supported but not always in the same way, which is why\nit hasn't managed to become part of POSIX.\n\nI for example stumbled upon an issue where 'local x' does not work the\nsame in bash and zsh, triggering a huge discussion on the zsh mailing\nlist.\n\nHowever, if you set a value (e.g. 'local x=') then you shouldn't have\nany problems.\n\n  f () { local x; echo ${x-unset}; }; f # this behavior varies\n\nFor a full discussion check [1].\n\n[1] https://www.austingroupbugs.net/bug_view_page.php?bug_id=767\n\n-- \nFelipe Contreras"},{"id":"423621","messageId":"YJHWJRYOcFEvHoD/@camp.crustytoothpaste.net","threadId":"55609","inReplyTo":"87a6pawmyu.fsf@evledraar.gmail.com","subject":"Re: [PATCH v2] CodingGuidelines: explicitly allow \"local\" for test scripts","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-05-04T23:17:57Z","receivedAt":"2021-05-04T23:18:37Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-05-04 at 15:09:54, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Tue, May 04 2021, Junio C Hamano wrote:\n> \n> > Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n> >\n> >> It's effectively synonymous with saying \"we still want to support git on\n> >> platforms that are so broken they can't even run a single test in our\n> >> test suite\".\n> >\n> > Not really.  Those on such a platform would (rightly) say that it is\n> > the test suite that is broken and out of compliance.\n> \n> Indeed. But the lack of any reports about that suggests that in practice\n> this is universally supported enough to be a hard dependency.\n> \n> In any case, it's clear you don't agree and you manage the patch\n> queue. So I'll leave it at that.\n\nI don't feel very strongly, but I would be fine with requiring local.\nOne of the main reasons the Austin Group is having trouble standardizing\nit is because some shells implement it with lexical scoping and some use\ndynamic scoping, but if we try not to make too many assumptions, we'll\nprobably be okay.\n\n> My aim here was to discover if we had any reason to think that \"local\"\n> was less universally implemented than other POSIX/C89-plus features we\n> rely on. It seems that it's not.\n\n\"local\" is missing in AT&T ksh.  As far as I'm aware, all of the other\nmajor open source shells support it: bash, dash, mksh, posh, and zsh,\nplus the default shells on most BSDs, so there are options for people\nwho would like to use Git on systems with a less capable shell.  As a\npractical matter, that means someone on a proprietary Unix or possibly a\nnon-Unix system.  In the latter case, we've only seen Plan 9, I believe,\nwhich is so devoid of reasonably functional basic Unix tools that it's\nprobably hopeless, and therefore we really only need to consider Windows\nand Unix systems.\n\nI should point out that we also make several non-POSIX assumptions about\nshell behavior in our testsuite.  I fixed one in c64368e3a2 (\"t9001:\navoid including non-trailing NUL bytes in variables\", 2019-11-27), but\nthe other one we make is that all components of a pipeline are run in\nsubshells, which is not true of AT&T ksh or zsh (in zsh mode), which run\nthe last item in the main shell.  This assumption used to break running\nzsh on our testsuite, but the developers recently accepted a patch to\nmake zsh in sh mode emulate what all other sh implementations do because\nthis assumption is so widespread that, as a practical matter, many\nthings break in such a case (the Git testsuite being one of them, but\nalso things like Debian's debconf).\n\nSo I'm okay with requiring a little more than POSIX behavior here\nbecause as a practical matter we already do and POSIX permits a wide\nvariety of behavior which is never implemented (e.g., running something\n_other_ than the last element in a pipeline in the main shell) and which\nwe could not practically test.  I agree that we should aim for targets\nwhich provide excellent compatibility and that when in doubt, we should\nlook to POSIX.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"423622","messageId":"xmqq35v26olz.fsf@gitster.g","threadId":"55609","inReplyTo":"YJHWJRYOcFEvHoD/@camp.crustytoothpaste.net","subject":"Re: [PATCH v2] CodingGuidelines: explicitly allow \"local\" for test scripts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-04T23:55:20Z","receivedAt":"2021-05-04T23:55:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n> One of the main reasons the Austin Group is having trouble standardizing\n> it is because some shells implement it with lexical scoping and some use\n> dynamic scoping, but if we try not to make too many assumptions, we'll\n> probably be okay.\n\nThanks for raising that one.  As long as we make sure that our\nscript would work with anybody's \"local\", I do not care very much.\nI just didn't think we want to spend the effort to explain that in\nthe documentation and enforce it---compared to the effort, just\nsaying \"no\" is certainly easier.\n\nBut if somebody wants an incremental patch on top to spell out how\n\"local\" is allowed to be used in our scripts, that's fine by me.\n"},{"id":"423623","messageId":"6091e1f12ddf9_cc8208b9@natae.notmuch","threadId":"55609","inReplyTo":"YJHWJRYOcFEvHoD/@camp.crustytoothpaste.net","subject":"Re: [PATCH v2] CodingGuidelines: explicitly allow \"local\" for test scripts","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-05T00:08:17Z","receivedAt":"2021-05-05T00:08:24Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"brian m. carlson wrote:\n> On 2021-05-04 at 15:09:54, Ævar Arnfjörð Bjarmason wrote:\n> > My aim here was to discover if we had any reason to think that \"local\"\n> > was less universally implemented than other POSIX/C89-plus features we\n> > rely on. It seems that it's not.\n> \n> \"local\" is missing in AT&T ksh.\n\nIt's not missing, it's supported only in \"functions\", which have a\ndifferent syntax in ksh:\n\n  function f { local x=\"foo\"; echo $x; }; f\n\n-- \nFelipe Contreras"},{"id":"423633","messageId":"YJH712E2kT9yJkGT@camp.crustytoothpaste.net","threadId":"55609","inReplyTo":"6091e1f12ddf9_cc8208b9@natae.notmuch","subject":"Re: [PATCH v2] CodingGuidelines: explicitly allow \"local\" for test scripts","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-05-05T01:58:47Z","receivedAt":"2021-05-05T01:59:25Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-05-05 at 00:08:17, Felipe Contreras wrote:\n> brian m. carlson wrote:\n> > On 2021-05-04 at 15:09:54, Ævar Arnfjörð Bjarmason wrote:\n> > > My aim here was to discover if we had any reason to think that \"local\"\n> > > was less universally implemented than other POSIX/C89-plus features we\n> > > rely on. It seems that it's not.\n> > \n> > \"local\" is missing in AT&T ksh.\n> \n> It's not missing, it's supported only in \"functions\", which have a\n> different syntax in ksh:\n> \n>   function f { local x=\"foo\"; echo $x; }; f\n\nI believe there's a bash compatibility mode that enables this, but I\ndon't see support for it in the version Debian ships[0], which doesn't\nenable that mode:\n\n  ksh -c 'function f { local x=\"foo\"; echo $x; }; f'\n  ksh: f[1]: local: not found [No such file or directory]\n\nIt's also possible that it may be aliased to \"typeset\" on some systems,\nin which case it may indeed work.\n\nRegardless of the specifics, I think we can both agree that it doesn't\nwork in sh-style functions, so for Git's purposes, AT&T ksh does not\nmeet our needs in terms of support for local.\n\n[0] I believe Debian's philosophy on this is that they ship bash, so\n    programs that need bashisms can just use bash.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"423639","messageId":"6092180651fdc_105ac2088a@natae.notmuch","threadId":"55609","inReplyTo":"YJH712E2kT9yJkGT@camp.crustytoothpaste.net","subject":"Re: [PATCH v2] CodingGuidelines: explicitly allow \"local\" for test scripts","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-05T03:59:02Z","receivedAt":"2021-05-05T03:59:08Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"brian m. carlson wrote:\n> On 2021-05-05 at 00:08:17, Felipe Contreras wrote:\n> > brian m. carlson wrote:\n> > > On 2021-05-04 at 15:09:54, Ævar Arnfjörð Bjarmason wrote:\n> > > > My aim here was to discover if we had any reason to think that \"local\"\n> > > > was less universally implemented than other POSIX/C89-plus features we\n> > > > rely on. It seems that it's not.\n> > > \n> > > \"local\" is missing in AT&T ksh.\n> > \n> > It's not missing, it's supported only in \"functions\", which have a\n> > different syntax in ksh:\n> > \n> >   function f { local x=\"foo\"; echo $x; }; f\n> \n> I believe there's a bash compatibility mode that enables this, but I\n> don't see support for it in the version Debian ships[0], which doesn't\n> enable that mode:\n> \n>   ksh -c 'function f { local x=\"foo\"; echo $x; }; f'\n>   ksh: f[1]: local: not found [No such file or directory]\n\nI tried to build ksh myself to make sure, and apparently there's a mess\nof different versions of it. I manually applied some patches and tried\nthree times before giving up.\n\nIt's clear the Debian version and the Arch Linux version are completely\ndifferent.\n\n> Regardless of the specifics, I think we can both agree that it doesn't\n> work in sh-style functions, so for Git's purposes, AT&T ksh does not\n> meet our needs in terms of support for local.\n\nIndeed. But it also probably doesn't meet many other needs. A quick\ncheck shows 54 failed tests just on t0000-basic.sh. I don't think it's\nsomething we should even consider.\n\nCheers.\n\n-- \nFelipe Contreras"},{"id":"423686","messageId":"YJKo02fG/riIetpu@coredump.intra.peff.net","threadId":"55609","inReplyTo":"6092180651fdc_105ac2088a@natae.notmuch","subject":"Re: [PATCH v2] CodingGuidelines: explicitly allow \"local\" for test scripts","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-05-05T14:16:51Z","receivedAt":"2021-05-05T14:16:54Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 04, 2021 at 10:59:02PM -0500, Felipe Contreras wrote:\n\n> > I believe there's a bash compatibility mode that enables this, but I\n> > don't see support for it in the version Debian ships[0], which doesn't\n> > enable that mode:\n> > \n> >   ksh -c 'function f { local x=\"foo\"; echo $x; }; f'\n> >   ksh: f[1]: local: not found [No such file or directory]\n> \n> I tried to build ksh myself to make sure, and apparently there's a mess\n> of different versions of it. I manually applied some patches and tried\n> three times before giving up.\n> \n> It's clear the Debian version and the Arch Linux version are completely\n> different.\n> \n> > Regardless of the specifics, I think we can both agree that it doesn't\n> > work in sh-style functions, so for Git's purposes, AT&T ksh does not\n> > meet our needs in terms of support for local.\n> \n> Indeed. But it also probably doesn't meet many other needs. A quick\n> check shows 54 failed tests just on t0000-basic.sh. I don't think it's\n> something we should even consider.\n\nYeah, we have visited this off and on over the years (links below).\nThere are some modernized ksh variants that work OK (like mksh), but I\nthink we've declared ksh93 as not worth it.\n\n-Peff\n\n[0] https://lore.kernel.org/git/31108626.20150508231514@gmail.com/\n[1] https://lore.kernel.org/git/xmqqinxt3kwq.fsf@gitster.mtv.corp.google.com/\n"},{"id":"423699","messageId":"6092d36c6d1a8_1d245208a4@natae.notmuch","threadId":"55609","inReplyTo":"YJKo02fG/riIetpu@coredump.intra.peff.net","subject":"Re: [PATCH v2] CodingGuidelines: explicitly allow \"local\" for test scripts","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-05T17:18:36Z","receivedAt":"2021-05-05T17:46:25Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeff King wrote:\n> On Tue, May 04, 2021 at 10:59:02PM -0500, Felipe Contreras wrote:\n> > Indeed. But it also probably doesn't meet many other needs. A quick\n> > check shows 54 failed tests just on t0000-basic.sh. I don't think it's\n> > something we should even consider.\n> \n> Yeah, we have visited this off and on over the years (links below).\n> There are some modernized ksh variants that work OK (like mksh), but I\n> think we've declared ksh93 as not worth it.\n\nJust to clarify what was said on that thread: ksh93 is not a version.\nThere is at least ksh93u+ and ksh93v-, which are *completely* different.\n\n-- \nFelipe Contreras\n"}]}