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

>To: Junio C Hamano <gitster@pobox.com>
>Cc: rsbecker@nexbridge.com; git@vger.kernel.org
>Subject: Re: [Test Breakage 2.46.0-rc0] Test t0021.35 fails on NonStop
>
>On 2024-07-14 at 17:00:12, Junio C Hamano wrote:
>> <rsbecker@nexbridge.com> writes:
>>
>> > This looks like a different between ksh and bash. Under bash, the
>> > test works. I can live with that but will have to force bash to be
>> > used as the shebang #!/bin/sh defaults to ksh on this box.
>>
>> It turns out that the version of ksh I used in my description does not
>> seem to grok "local" at all. I vaguely recall that we've written off
>> various hobbist reimplementation of ksh as unusable enough, but this
>> one is ksh93 direct from AT&T Research.
>>
>> I guess when we said "as long as we limit our use to a simple 'this
>> variable has visibility limited to the function and its children'
>> and nothing else, it is portable enough across practically everybody
>> we care about", we have written off the real ksh, too.
>>
>> In the meantime, we may want to document this in a more prominent way.
>> Perhaps like so:
>>
>> -------- >8 --------------- >8 --------------- >8 --------
>> Subject: doc: guide to use of "local" shell language construct
>>
>> The scripted Porcelain commands do not allow use of "local" because it
>> is not universally supported, but we use it liberally in our test
>> scripts, which means some POSIX compliant shells (like "ksh93") can
>> not be used to run our tests.
>>
>> Document the status quo, and hint that we might want to change the
>> situation in the fiture.
>
>I don't think this is the right approach.  Every version of ksh _except_ AT&T ksh
>works just fine here.  pdksh, mksh, lksh, OpenBSD's ksh (which is also its /bin/sh)
>work fine, as do bash, dash, FreeBSD's sh (ash), Busybox's sh (also ash), and zsh
>(when run in sh mode with 5.9 or newer).  AT&T ksh is considering adding local in a
>newer version for this reason.
>
>Literally only AT&T ksh is not supported here, and so anyone can set SHELL_PATH to
>any suitable shell.  I don't think it's useful to get rid of local when there are a variety
>of acceptable and portable options.