mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "brian m. carlson" <>
To: "Ævar Arnfjörð Bjarmason" <>
Cc: Junio C Hamano <>,
	Git List <>,
	Eric Sunshine <>
Subject: Re: [PATCH v2] CodingGuidelines: explicitly allow "local" for test scripts
Date: Tue, 4 May 2021 23:17:57 +0000	[thread overview]
Message-ID: <YJHWJRYOcFEvHoD/> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 3111 bytes --]

On 2021-05-04 at 15:09:54, Ævar Arnfjörð Bjarmason wrote:
> On Tue, May 04 2021, Junio C Hamano wrote:
> > Ævar Arnfjörð Bjarmason <> writes:
> >
> >> It's effectively synonymous with saying "we still want to support git on
> >> platforms that are so broken they can't even run a single test in our
> >> test suite".
> >
> > Not really.  Those on such a platform would (rightly) say that it is
> > the test suite that is broken and out of compliance.
> Indeed. But the lack of any reports about that suggests that in practice
> this is universally supported enough to be a hard dependency.
> In any case, it's clear you don't agree and you manage the patch
> queue. So I'll leave it at that.

I don't feel very strongly, but I would be fine with requiring local.
One of the main reasons the Austin Group is having trouble standardizing
it is because some shells implement it with lexical scoping and some use
dynamic scoping, but if we try not to make too many assumptions, we'll
probably be okay.

> 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.  As far as I'm aware, all of the other
major open source shells support it: bash, dash, mksh, posh, and zsh,
plus the default shells on most BSDs, so there are options for people
who would like to use Git on systems with a less capable shell.  As a
practical matter, that means someone on a proprietary Unix or possibly a
non-Unix system.  In the latter case, we've only seen Plan 9, I believe,
which is so devoid of reasonably functional basic Unix tools that it's
probably hopeless, and therefore we really only need to consider Windows
and Unix systems.

I should point out that we also make several non-POSIX assumptions about
shell behavior in our testsuite.  I fixed one in c64368e3a2 ("t9001:
avoid including non-trailing NUL bytes in variables", 2019-11-27), but
the other one we make is that all components of a pipeline are run in
subshells, which is not true of AT&T ksh or zsh (in zsh mode), which run
the last item in the main shell.  This assumption used to break running
zsh on our testsuite, but the developers recently accepted a patch to
make zsh in sh mode emulate what all other sh implementations do because
this assumption is so widespread that, as a practical matter, many
things break in such a case (the Git testsuite being one of them, but
also things like Debian's debconf).

So I'm okay with requiring a little more than POSIX behavior here
because as a practical matter we already do and POSIX permits a wide
variety of behavior which is never implemented (e.g., running something
_other_ than the last element in a pipeline in the main shell) and which
we could not practically test.  I agree that we should aim for targets
which provide excellent compatibility and that when in doubt, we should
look to POSIX.
brian m. carlson (he/him or they/them)
Houston, Texas, US

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

  parent reply	other threads:[~2021-05-04 23:18 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-03  4:10 [PATCH] CodingGuidelines: explicitly allow "local" for test scripts Junio C Hamano
2021-05-03  4:21 ` Eric Sunshine
2021-05-03  5:21   ` Junio C Hamano
2021-05-03  5:23     ` [PATCH v2] " Junio C Hamano
2021-05-03  9:01       ` Ævar Arnfjörð Bjarmason
2021-05-04  3:01         ` Junio C Hamano
2021-05-04 12:27           ` Ævar Arnfjörð Bjarmason
2021-05-04 12:50             ` Junio C Hamano
2021-05-04 15:09               ` Ævar Arnfjörð Bjarmason
2021-05-04 20:22                 ` Felipe Contreras
2021-05-04 23:17                 ` brian m. carlson [this message]
2021-05-04 23:55                   ` Junio C Hamano
2021-05-05  0:08                   ` Felipe Contreras
2021-05-05  1:58                     ` brian m. carlson
2021-05-05  3:59                       ` Felipe Contreras
2021-05-05 14:16                         ` Jeff King
2021-05-05 17:18                           ` 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:

  List information:

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

  git send-email \
    --in-reply-to=YJHWJRYOcFEvHoD/ \ \ \ \ \ \

* 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

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).