Eli Schwartz <eschwartz@xxxxxxxxxx> writes: > 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?
