Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela 12 Aug 2019 11:52 UTC
> (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. There's nothing stupid about (user-info:name (user-info (user-uid))) in my book. It reads naturally and clearly shows how it maps to the OS facilities. Are you opposed to it? > 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. That is a good argument. > 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. Not true. It may be a full name for 99% of passwd entries, but 99% of systems are definitely not devoid of entries using commas/ampersands. Linux routinely makes passwd entries that use commas, and the BSDs ship with passwd entries that use ampersands. Also check my survey: most systems say in their documentation that commas and/or ampersands are recognized. If we serve the raw GECOS field as "full-name", that claim will often be incorrect. If we serve it by the name "gecos", that name doesn't mean anything on non-Unix operating systems (whereas full-name probably has natural equivalents on most OSes). FWIW, POSIX doesn't even mandate having a gecos field at all. > > 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. You're right - it is a good principle to isolate a minimal OS interface. In that case, I would be in favor of providing readlink and getenv (not necessarily in the same SRFI). They are more generally useful.