Stefan wrote:
Hi Jacob!
the dejagnu(1) launcher now first walks the PATH returned by `getconf
PATH` (and then the user's $PATH) for an "sh" in search of a POSIX
shell.
Does this also fix your problem?
Kind of. The getconf tool is missing in Guix, not only during the
bootstrapping I'm trying. Actually it is part of glibc, but the glibc
tools are usually not in PATH. If getconf is missing, the dejagnu
script prints an annoying error message, which can be ignored:
# LANG=C_LANG dejagnu --version
dejagnu-1.6.3-checkout/dejagnu: line 76: getconf: command not found
dejagnu auxiliary launcher (DejaGnu) 1.6.4-git
Maybe change that line to suppress the error message:
SysPATH=`getconf PATH 2> /dev/null`
The change from the traditional GNU assumption that /bin/sh is a Bourne
shell to walking the PATH in search of POSIX sh is justified as POSIX
conformance; POSIX says that getconf(1) exists, so I will call this
either a system configuration issue or a bug in Guix. The error will
/not/ be suppressed---it could be the key to recognizing an issue if the
tool is run on a non-POSIX or pre-POSIX system. (In which case, there
might actually /not/ be a POSIX awk or sh anywhere to be found.)
However, the path returned from getconf—if made available—is
/bin:/usr/bin. But in a Guix build environment, for example when
building and testing binutils, there is no /bin available and neither
a /usr. So even if the getconf is provided during build, its result
is a lie. But that's not the problem of dejagnu at all.
The fact that the GNU system does not strictly follow POSIX on this is
the reason that the launcher also searches the user's PATH. (I also
seem to remember an off-hand remark somewhere that "/usr" is supposed to
be a symlink back to "/" in the GNU system.) According to POSIX, we
should be able to just do "PATH=`getconf PATH`" and forget about it,
with all system utilities now available, but I already know that will
not be reliable on the GNU system. POSIX specifies that getconf(1)
returns information according to the execution environment; perhaps
glibc should be able to get at least some configuration strings from a
file /etc/conf.posix listing system variables and their values?
-- Jacob
