>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