Re: [PATCH v3 2/2] meson: prefer shell at "/bin/sh"

From: Eli Schwartz <eschwartz@gentoo.org>
Date: Apr 25, 2025, 22:25 UTC
Message-ID: <9182bbb9-fdfa-4abe-abae-4ecfd5c0f449@gentoo.org>
In-Reply-To: <aAvsT1o6wIGGCEui@tapette.crustytoothpaste.net>

On 4/25/25 4:10 PM, brian m. carlson wrote:

> All of what you said here is true, but I will point out that AT&T ksh
> (ksh93 and also ksh88) doesn't support `local`.  All of the others do,
> as do other pdksh derivatives (like OpenBSD's sh and ksh[0]).

Right, though I seem to recall e.g. all the BSDs use a pdksh variant at least.

> I believe on NonStop that `sh` is AT&T ksh, so there is no program or
> symlink named `sh` on the system which meets our needs.  The customary
> option there is to use bash instead.

Aha. :(

Show 7 quoted lines

> Additionally, Debian allows zsh as `/bin/sh`, since it meets their
> requirements, but older versions do not run all elements of a pipeline
> in a subshell, which, while allowed by POSIX as an extension,
> practically breaks our code (and lots of other code as well).  (New
> versions contain a patch I sent that fixes this behaviour when in `sh`
> mode.)  As a result, a user compiling their own Git might need to
> specify something that is not `sh` on such a system.

Nobody should be using zsh as /bin/sh at all, since it is not a POSIX shell to begin with. e.g. Gentoo does not permit it. I think Debian should treat this as a conformance bug and fix it by removing zsh support for /bin/sh until upstream zsh makes a serious effort to conform to POSIX (i.e. never)...

> And Junio points out correctly that some systems have Perl as `perl5`,
> not `perl`.  (Mostly in environments that once had or still have Perl
> 4.)

Yup. Same applies for overriding via a machine specification file as I replied regarding "sh".

> So all that to say that we do need to be able to specify an arbitrary
> path to a binary in order for things to work on some systems.
> 
> [0] Which are the same thing.

-- 
Eli Schwartz