Thanks! (getenv "USER") is the other possible route. Forcing users to
pick one of those two manual routes instead of having an abstract
(user-login-name) procedure makes things more explicit.
But also more stupid. I'm not sure what to do here after all. You'll always get an answer (on actual Posix systems), even if it isn't the answer the user actually wants.
We could also put all the user/group database procedures in their own
SRFI. I think they are pretty well isolated from other OS interfaces.
-1, for the reason I gave above: interpreting file-info entries.
Things that deal with user/group _numbers_ pertaining to the current
process, such as (user-uid) et.al., should probably be in the same SRFI
as the process and signal stuff.
+1
Yeah, it's pretty much the "crud that doesn't fit anywhere else" field
:D I can't think of a good name for it either. One more possibility is
"comment field".
It's a full name 99% of the time nowadays. Let's keep the name.
> current-timezone, which can be picked up from the TZ environment
> variable, and in general deserves being part of its own SRFI.
Agree that it should go into a date and time SRFI.
-1. I want date/time to be fully portable, no dependencies on the current anything except the current TAI-UTC table, which is unavoidable. See TimeAdvancedCowan. See also my previous post for the issue with TZ.