On 4/25/25 4:10 PM, brian m. carlson wrote: > 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]). Right, though I seem to recall e.g. all the BSDs use a pdksh variant at least. > 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. Aha. :( > 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. Nobody should be using zsh as /bin/sh at all, since it is not a POSIX shell to begin with. e.g. Gentoo does not permit it. I think Debian should treat this as a conformance bug and fix it by removing zsh support for /bin/sh until upstream zsh makes a serious effort to conform to POSIX (i.e. never)... > 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.) Yup. Same applies for overriding via a machine specification file as I replied regarding "sh". > 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. -- Eli Schwartz
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
