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

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Apr 25, 2025, 20:10 UTC
Message-ID: <aAvsT1o6wIGGCEui@tapette.crustytoothpaste.net>
In-Reply-To: <06e57780-9f59-4166-81d3-9cd0c1c66b7e@gentoo.org>

On 2025-04-25 at 18:07:18, Eli Schwartz wrote:

Show 27 quoted lines

> On 4/25/25 1:04 PM, Junio C Hamano wrote:
> > Now I am showing my ignorance, but does this support folks whose
> > shell are not spelled "sh" (like "/usr/local/bin/dash"), and more
> > importantly, if it does not, shouldn't we be using a mechanism that
> > does?  I think -Dsane_tool_path=/usr/local/bin would help with the
> > leading directory path, but I suspect that find_program() does not
> > help specifying "dash" to be used as our target_shell (or host
> > shell), or "perl5" as our perl.
> > 
> > Of course, this "my sh is called dash" can be left totally outside
> > of the topic of these two patches.
> 
> 
> POSIX does not require a specific absolute file path for "sh", but it
> does mandate that you have a shell and its name is "sh", whichever
> directory it may be found in.
> 
> There is (most of the time) not actually a program called "sh". Various
> different programs may provide a symlink "sh", pointing to their own shell:
> 
> - GNU Bash (bash)
> - Korn Shell (ksh93)
> - Policy-compliant Ordinary Shell (Debian `posh`)
> - Almquist Shell (ash)
> - Debian Almquist Shell (dash)
> - busybox
> - MirBSD Korn Shell (mksh)

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

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.

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.

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

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.

-- 
brian m. carlson (they/them)
Toronto, Ontario, CA