That seems worse. Linux's getlogin(3) says in Description that $LOGNAME
is often more useful, and its Bugs section is an amusing read.
getlogin(3p) from POSIX is also available for detail.
I'm not so crazy on using getlogin() since this function can be called
by nmh programs that do not have a controlling terminal.
getlogin() copes with multiple usernames for the same ID and finds the
one used on this controlling terminal, checking FDs 0-2 until ‘success’
and crawling utmp. That's overkill for our purposes. $LOGNAME is in
our memory and a function call away, plus it's easy to document and
useful to override.
It sure does seem like the overarching lesson from this is "think carefully
about any change you make to nmh since unintended consequences abound".
getusername() (the nmh function) is called by programs like slocal and
rcvtty, which may not have a controlling terminal and I am unclear what
LOGNAME would mean in their environment as well. We could do something
like call isatty(0) before falling back to LOGNAME, but then I'd have to
ask "exactly WHY are we doing that?".
I am thinking that falling back to getpwuid(getuid()) is the most reasonable
approach, for the following reasons:
- My vague impression is that this is what most other programs who want
this information do.
- It is consistent with MH historical practice and is thus likely to have
the fewest unintended consequences
- Should generally work across program execution environments
- Even though it might be useful to override the username with an environment
variable, AFAICT the actual use of the username can be overridden by a
command line switch in all programs that call getusername().
Thoughts?
--Ken
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers