On Fri, Apr 25, 2025 at 10:49:10AM +0000, brian m. carlson wrote:
> On 2025-04-25 at 05:47:45, Patrick Steinhardt wrote:
> > Meson detects the path of the target shell via `find_program("sh")`,
> > which essentially does a lookup via `PATH`. This may easily lead to a
> > subtly-broken Git distribution when the build host has its shell in a
> > non-standard location that the target host doesn't know about.
> >
> > Fix the issue by appending "/bin" to the custom program path, which
> > causes us to prefer "/bin/sh" over a `PATH` lookup. As this location is
> > specified by POSIX this should make us pick a better default shell path
> > on all POSIX-compliant systems.
>
> Can you provide a citation for that? I don't see that in the POSIX
> 1003.1-2024 directory structure document[0]. More specifically, I think
> there are some proprietary Unix systems where `/bin/sh` is the original
> Bourne shell and is not POSIX compliant and some other path is the
> POSIX-compliant `sh`.
Hrmpf, you're right. I feel like I relearn this piece of trivia every
couple years. POSIX is quite specific here:
Applications should note that the standard PATH to the shell cannot
be assumed to be either /bin/sh or /usr/bin/sh, and should be
determined by interrogation of the PATH returned by getconf PATH ,
ensuring that the returned pathname is an absolute pathname and not
a shell built-in.
Anyway, given the following...
> I'll also point out that we require more than POSIX compliance in that
> we require `local`, so even if `/bin/sh` is POSIX compliant, that
> doesn't mean that it's suitable for Git. `/bin/sh` meets our needs on
> all the Linux distros I'm aware of, plus the BSDs, but if it were AT&T
> ksh, that would not meet our needs since it doesn't support `local`,
> even though it's POSIX compliant.
... prefering "/bin/sh" is still the right thing to do as it tends to
work on most systems supported by us, even though it's non-POSIX. But in
any case, the commit message needs to be adjusted.
Thanks!
Patrick
