On 4/25/25 2:51 PM, Junio C Hamano wrote:
> Eli Schwartz <eschwartz@xxxxxxxxxx> writes:
>> 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.
I would argue 100% of interactive bash users, are running "bash" to get
it. They are not running "sh" and then rewriting all scripts in /usr/bin
from
#!/bin/sh
to
#!/usr/bin/dash
for the speedup.
The point is that if users set the "non-interactive scripts" command
/bin/sh to GNU bash, they are fine with that being used everywhere (and
it will in fact run all Git's scripts well).
> 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?
But it's a very fair point that it's possible to need more than just
POSIX. Meson can override program lookup:
$ cat paths.ini
[binaries]
sh = '/usr/bin/bash'
$ meson setup builddirbash/ --native-file=paths.ini
[...]
Runtime executable paths
perl : /usr/bin/perl
python : /usr/bin/python3
shell : /usr/bin/bash
A dedicated build option might be more discoverable, but it's certainly
possible to override this today. Autodetecting the right one can be
tricky...
--
Eli Schwartz
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
