On Thu, Aug 08, 2019 at 11:35:38AM +0000, brian m. carlson wrote:
> On 2019-08-08 at 09:37:33, Jeff King wrote:
> > On Wed, Aug 07, 2019 at 11:56:14PM -0700, Jonathan Nieder wrote:
> > -- >8 --
> > Subject: [PATCH] t0000: reword comments for "local" test
> >
> > Commit 01d3a526ad (t0000: check whether the shell supports the "local"
> > keyword, 2017-10-26) added a test to gather data on whether people run
> > the test suite with shells that don't support "local".
> >
> > After almost two years, nobody has complained, and several other uses
> > have cropped up in test-lib-functions.sh. Let's declare it acceptable to
> > use.
>
> I'm also in favor of this patch. To my knowledge, the only FLOSS
> POSIX-compliant shell that doesn't support "local" is AT&T ksh, so there
> are a lot of alternatives that folks have (bash, dash, posh, zsh, mksh,
> pdksh, busybox sh, etc.) in case they have a less capable shell.
>From these shells:
- dash and Bash work; no surprise there, being the default shells in
some of the most popular Linux distros and GfW.
- mksh works as well (just don't hit ctrl-C while running a test
involving a daemon with '--verbose-log').
- Zsh seems to be fundamentally incapable to run our test
framework.
- BusyBox sh is fine for the most part, but there are a few test
failures, where we rely on some options or capabilities of various
system commands that are not supported by the corresponding
BusyBox builtins.
- posh can successfully run a lot of test scripts, but there are a
lot of failures as well, it skips a few test scripts that it
shouldn't (claiming that Perl and Bash are not available?!), and
t0000 aborts with a 'bug in test framework' error. What's most
worrying is that it reported a few "known breakage fixed" cases as
well.
- pdksh seems to be unavailable in my Linux distro, but since its
name contains the "ksh" substring I'm sceptical.
So there are not that many alternatives.
Having said that, I'm in favor of using 'local'.
