git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
	git@vger.kernel.org, "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"SZEDER Gábor" <szeder.dev@gmail.com>,
	"Eric Sunshine" <sunshine@sunshineco.com>
Subject: Re: [PATCH 0/6] test: make the test suite work with zsh
Date: Wed, 29 Mar 2023 15:54:01 -0600	[thread overview]
Message-ID: <CAMP44s0eSDBXZEN9fRPdxV4GKLqckKtujMLDPORDjHfsdypDBQ@mail.gmail.com> (raw)
In-Reply-To: <xmqqh6u3d119.fsf@gitster.g>

On Wed, Mar 29, 2023 at 9:34 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> "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

  reply	other threads:[~2023-03-29 21:54 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-28 17:39 [PATCH 0/6] test: make the test suite work with zsh Felipe Contreras
2023-03-28 17:39 ` [PATCH 1/6] test: fix build for zsh Felipe Contreras
2023-03-28 17:39 ` [PATCH 2/6] test: avoid `stat` variable Felipe Contreras
2023-03-29  9:48   ` Ævar Arnfjörð Bjarmason
2023-04-01  0:05   ` Taylor Blau
2023-04-01  0:25     ` Felipe Contreras
2023-03-28 17:39 ` [PATCH 3/6] test: avoid `options` variable Felipe Contreras
2023-03-28 17:39 ` [PATCH 4/6] test: avoid `path` variable Felipe Contreras
2023-03-28 17:39 ` [PATCH 5/6] test: hack for zsh Felipe Contreras
2023-03-30  8:15   ` Felipe Contreras
2023-03-28 17:39 ` [PATCH 6/6] mergetools: vimdiff: check for empty fields Felipe Contreras
2023-03-29  0:57 ` [PATCH 0/6] test: make the test suite work with zsh brian m. carlson
2023-03-29  1:57   ` Felipe Contreras
2023-03-29  9:51     ` Ævar Arnfjörð Bjarmason
2023-03-29 11:19       ` Felipe Contreras
2023-03-30 13:00         ` Felipe Contreras
2023-03-29 15:34   ` Junio C Hamano
2023-03-29 21:54     ` Felipe Contreras [this message]
2023-03-30 10:15       ` Junio C Hamano
2023-03-30 14:19         ` Felipe Contreras
2023-04-01  0:04           ` Taylor Blau
2023-04-01  0:59             ` Felipe Contreras
2023-04-01  1:30           ` Junio C Hamano
2023-04-01  2:39             ` Felipe Contreras
2023-04-01  0:00         ` Taylor Blau
2023-04-01  0:50           ` Felipe Contreras
2023-03-29 22:14     ` brian m. carlson
2023-03-30  3:15       ` Junio C Hamano
2023-03-30  7:47         ` Felipe Contreras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMP44s0eSDBXZEN9fRPdxV4GKLqckKtujMLDPORDjHfsdypDBQ@mail.gmail.com \
    --to=felipe.contreras@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sandals@crustytoothpaste.net \
    --cc=sunshine@sunshineco.com \
    --cc=szeder.dev@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).