Stefan wrote:
Can you provide more information about your environment, in
particular how whoami(1) failed?
I'm playing around with the source bootstrap process of Guix¹. The
built Binutils has some issue and I want to run its testsuite. There
is no Coreutils at this stage but only gash-utils², which provides a
subset of commands with only limited functionality.
I see: you are doing a bootstrap and are still reliant on bootstrap
tools, which do not provide a login environment. (So neither USER nor
LOGNAME is set, either, and presumably everything is "root" because
accounts do not yet exist. Fun...)
In the first place I was wondering why at all logname is needed.
I can guess the reason for putting the user's login name into the log
based on DejaGnu's history: DejaGnu originated at Cygnus, where the
ability to easily look at a log and see who had run the tests meant
knowing who to ask about the results. I suspect that Cygnus had quite a
bit of shared infrastructure and test results may have been passed
around instead of each developer working in relative isolation as is now
common. (I.e. one person runs the tests, but several work to chase down
the failures.)
That said, there is an issue here: DejaGnu is supposed to declare that
the user running the tests is unknown rather than fail. As of commit
7be57b729931bbdfa0770eabe4e7586170b28b1f the problem should be fixed;
please confirm that it is. (I took the opportunity to clean up the code
while in there.)
This code dates back to the beginning of the repository history and
ChangeLog-1992 suggests that it likely originated in 1993 or 1994.
Those error messages presumably are from some particular (now
archaic) environment that did not have whoami(1), but unless Tcl's
evaluation semantics have changed, this misuse of catch(n) should
have blown up then, too. I am a bit confused how this could have
gone unnoticed for so long.
Yes, I saw that, too. I assume whoami was used without a catch in the
beginning and someone added the catch wrongly without having an actual
problem with it.
I am particularly curious about the systems that used "who am i" instead
of "whoami" and the further processing done in that last case.
If you are actually the first person to have tried running DejaGnu on
a system lacking both of the USER and LOGNAME environment variables
and the whoami(1) command, I am not sure that the fallback for a
missing whoami(1) is still relevant. (If it never worked, then I am
unsure that it was ever relevant.)
I would even go a step further and argue that logname should be
dropped. It is only used to put the user's name into a log-file. You
could treat it as a data leak and problematic for reproducibility.
Reproducibility for DejaGnu logs to that level is not going to happen,
since the log will definitely contain timestamps. The log needs to have
enough information to distinguish test runs---wasting time running down
a failure that has already been fixed is unacceptable.
I also find the idea of the account name under which the test was run
being some kind of "data leak" to be a bit ridiculous. It is near the
top of the log and can easily be anonymized if that is an actual
concern, which I expect to be rather unlikely. In the normal case, it
is on the same line as a timestamp, so that line would be ignored in a
reproducibility check anyway.
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...
-- Jacob
