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

Reply via email to