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

From: Eli Schwartz <eschwartz@gentoo.org>
Date: Apr 25, 2025, 18:07 UTC
Message-ID: <06e57780-9f59-4166-81d3-9cd0c1c66b7e@gentoo.org>
In-Reply-To: <xmqqy0votbns.fsf@gitster.g>

On 4/25/25 1:04 PM, Junio C Hamano wrote:

Show 10 quoted lines

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

(Commercial Unixes will tend to have a unique "sh" program without an actual name, just called "$UNIX sh".)

You can call them by either name, but the general rule is that when running an interactive command prompt you probably have your specific favorite whereas when running a script you just need something that complies with the POSIX spec. It's common to install dash as the /bin/sh because it is faster than GNU Bash due to supporting much less.

There cannot be anyone who has a sh that is not spelled "sh", there are only people who have multiple options, one of which has been assigned to the name "sh".

If it is desirable for Git to allow people to experiment with different shells for the git internal scripts, that is one thing (though I don't think it's particularly useful). But there's no need to worry about people that don't have an "sh". They have to.

Even on Solaris where /bin/sh is a non-POSIX shell that cannot run our scripts, that is a backwards compatibility requirement and they expect you to add /usr/xpg4/bin to the front of $PATH for applications that use POSIX, while leaving the "broken forever" version in /bin to be used by legacy pre-1990s applications that may still exist and haven't been updated in well over 30 years and counting. The "sh" in $PATH at /usr/xpg4/bin/sh is a POSIX-compliant shell. It even has the `local` vendor extension.

-- 
Eli Schwartz