Re: [PATCH 0/6] test: make the test suite work with zsh

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Mar 29, 2023, 21:54 UTC
Message-ID: <CAMP44s0eSDBXZEN9fRPdxV4GKLqckKtujMLDPORDjHfsdypDBQ@mail.gmail.com>
In-Reply-To: <xmqqh6u3d119.fsf@gitster.g>

On Wed, Mar 29, 2023 at 9:34 AM Junio C Hamano <gitster@pobox.com> wrote:

Show 15 quoted lines

>
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>
> > I don't care a lot of other folks want to make zsh run the
> > testsuite in zsh mode, but I'd think that using sh mode would be
> > simpler and less likely to break in general, and would avoid us
> > needing to carry a lot of patches to work around various variables
> > that are special in zsh mode.  It would also be easier to
> > potentially test in the testsuite as well.
>
> While these patches may make it "work" with zsh in its native mode,
> because zsh that is running in its native mode is sufficiently
> distant from the more POSIXy portable variants of Bourne shells like
> dash and bash, I find it hard to justify the cost of maintaining the
> resulting codebase to "work" that way.

Why do we follow POSIX anyway?

Is it a) because following POSIX is just good? Or b) because POSIX is a standard that many shells attempt to follow and thus by following POSIX we maximize the amount of code that works on most shells?

A quick non-exhaustive search of the history of Git, shows these:

74ec8cf674 Conform to POSIX (works in mksh/lksh) c5c39f4e34 Fix for dash 7d661e5ed1 Conform with POSIX (works with dash and mksh) ddf3a1152d Remove a warning in bash 9b67c9942e Workaround for ksh 5c63920190 Consideration for some shells (e.g. ksh93) e9980419cb Fails in ksh88 268ef4d3d0 Aligns with POSIX 8e98b35f87 ksh88 on AIX considers it a syntax error 8f92c7755e Code would break under mksh b082687cba Not allowed in mksh 661bfd13b4 Fails in xpdg4/sh and ksh f5799e05c0 Public domain ksh and ksh on IRIX 6.5 have a problem 365c2aaafc Doesn't work in pdksh, POSIX unclear 482ce70e14 Doesn't work in dash and ash 77e572653b Doesn't work in dash 0e418e568f Workaround for ksh 49a43f5468 ksh doesn't like this c289c315c2 Doesn't work in xpg4/sh 933e4f090d Workaround possible dash bug c7053aa88f Doesn't seem to be supported by dash

It does seem like in only around 15% of these patches the consideration was "this aligns with POSIX", in most cases the patch was to make the code work for a particular shell.

In most cases the mention of POSIX is used as a justification for the proposed code, but it was clear the intention was to make it work for a specific shell (usually ksh).

In the few cases where POSIX was the main rationale, the shells in which the current code doesn't work are mentioned. Not a single patch says "this aligns with POSIX" without mentioning any shell.

> We need to force our developers to pay attention to rules set by
> zsh, like "$0 is not the way to spell the name of the script",
> "$status is not usable by end-users", etc.  Making the problem
> worse, the rules are enforced only by zsh.

No, we don't. $0 is not something a test script needs. In fact, there doesn't seem to be a single instance in which $0 is used except test infrastructure (e.g. test-lib.sh)

This sounds like a rationalization post-decision rather than a reason for the decision.

Looking at the history it seems the test code has been more than happy to make accommodations for xpg4/sh, pdksh, ash, and even mksh, even when the code was already POSIX-compliant.

In truth all the patches regarding shell portability have been along the lines of: "this code makes $x shell work, doesn't break other shells, and isn't against POSIX". In some cases even when the Austin group disagreed on what POSIX actually said, we did whatever worked in most shells.

Is there some sort of predisposition against zsh?

Cheers.

-- 
Felipe Contreras