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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 25, 2025, 18:51 UTC
Message-ID: <xmqqcyd0t6qx.fsf@gitster.g>
In-Reply-To: <06e57780-9f59-4166-81d3-9cd0c1c66b7e@gentoo.org>

Eli Schwartz <eschwartz@gentoo.org> writes:

Show 19 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:

Exactly. And with many systems being personal these days, /bin/sh may point at a shell that is better for interactive use (like "bash"), while the user may prefer another (like "dash") scripted use that is not pointed by that single /bin/sh symbolic link.

In any case, we live in real world where things are not strictly POSIX. Our Makefile does support with SHELL_PATH "sh", "dash", and "bash" just fine. Why shouldn't I wish for feature parity in a new build framework that aims to at least compete and become an alternative?