Re: [PATCH v2] CodingGuidelines: explicitly allow "local" for test scripts
- From
brian m. carlson <sandals@crustytoothpaste.net>
- Date
- May 5, 2021, 01:58 UTC
- Message-ID
- <YJH712E2kT9yJkGT@camp.crustytoothpaste.net>
- In-Reply-To
- <6091e1f12ddf9_cc8208b9@natae.notmuch>
On 2021-05-05 at 00:08:17, Felipe Contreras wrote:
Show 12 quoted lines
> brian m. carlson wrote:
> > On 2021-05-04 at 15:09:54, Ævar Arnfjörð Bjarmason wrote:
> > > My aim here was to discover if we had any reason to think that "local"
> > > was less universally implemented than other POSIX/C89-plus features we
> > > rely on. It seems that it's not.
> >
> > "local" is missing in AT&T ksh.
>
> It's not missing, it's supported only in "functions", which have a
> different syntax in ksh:
>
> function f { local x="foo"; echo $x; }; fI believe there's a bash compatibility mode that enables this, but I don't see support for it in the version Debian ships[0], which doesn't enable that mode:
ksh -c 'function f { local x="foo"; echo $x; }; f'
ksh: f[1]: local: not found [No such file or directory]It's also possible that it may be aliased to "typeset" on some systems, in which case it may indeed work.
Regardless of the specifics, I think we can both agree that it doesn't work in sh-style functions, so for Git's purposes, AT&T ksh does not meet our needs in terms of support for local.
[0] I believe Debian's philosophy on this is that they ship bash, so
programs that need bashisms can just use bash.-- brian m. carlson (he/him or they/them) Houston, Texas, US