Re: [PATCH] Catch errors properly, if whoami or who don't exist

Maciej W. Rozycki wrote:
> On Fri, 6 Sep 2024, Jacob Bachmeyer wrote:
>
>   
>>> By the way, I need another patch, as /bin is not existing in my case.  I'm
>>> actually a bit wondering why all tools like awk, expect, tcl have a fallback
>>> without a path just to their executable name, but sh needs a fallback to
>>> /bin/sh.  But anyway, this is a common problem packaging software for Guix
>>> and not a problem of DejaGnu.
>>>       
>> That is because most tools can be in varying places, but there is a
>> long-established *nix convention that the system shell is exactly "/bin/sh"
>> and that shell is a Bourne shell of some type.  The scripts in DejaGnu that
>> expect to use it are accordingly written to run within the restrictions of
>> even ancient Bourne shells, which is one of the reasons that dejagnu(1) does
>> not itself search the PATH, instead relying on the shell running it to do so
>> when needed.
>>
>> There is a technical reason for this assumption about /bin/sh:  the #!
>> mechanism does not search $PATH and requires an absolute filename.
>>
>> In fact, how are you even running the dejagnu(1) and runtest(1) scripts if
>> /bin/sh does not exist?  Their #! lines refer to /bin/sh...
>>     
>
>  POSIX says otherwise, you must not rely on the presence of /bin/sh; cf. 
> <https://pubs.opengroup.org/onlinepubs/9799919799/utilities/sh.html#tag_20_110_16>.
> The path to the interpreter can be easily substituted e.g. with autoconf.
>   

That is in an informative section; and it is indeed correct that /bin/sh 
cannot be assumed to be a POSIX shell.  The scripts that use #!/bin/sh 
in DejaGnu avoid making such an assumption.  That section also says that 
you are supposed to be able to find a POSIX shell with `command -v sh` 
but I suspect that Autoconf does considerably more work than that to 
locate a suitable shell.  I will think about this; it would be nice for 
auxiliary command scripts to be able to assume a POSIX shell.

However, dejagnu(1) does use command(1) (the systems on the cfarm where 
it is not a shell builtin in /bin/sh have it as an actual command in the 
PATH) and perhaps runtest(1) should be adjusted to similarly use 
command(1) to search the PATH instead of its current "hand-rolled" search.


-- Jacob