Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela 11 Aug 2019 15:10 UTC
> user-login-name, which as Lassi notes, "is reliably accomplished via > (user-info:name (user-info (user-uid)))", that the passwd database is > the source of truth, but the routines that query it can be overridden > with e.g. a LD_PRELOAD hack. John agreed user-login-name should go, I > will add a note pointing out Lassi's alternative. 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. Not sure what the usual Windows API function is to get the login name. I think Windows also keeps an environment variable with the name but it's no more reliable than the Unix USER variable. > I originally advocated against all of 3.6 User and group database > access, user-info and group-info, but there are solid arguments for them > including the above observation by Lassi. 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. 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. > I note group-info:members is particularly messy to get back from the > library call, and Lassi notes "getgroups() [ which the SRFI supplies as > (user-supplementary-gids) ] gets the full list of your own supplementary > groups." Agree that it should go. It could be included in a separate user database SRFI, but since even getpwent()'s own manual page advises that one probably shouldn't use it, it may be best to let it go altogether :) > Therefore I advocate we remove group-info:members from the > group-info record, and make a note about user-supplementary-gids in the > 3.6 section. Agreed. > I further advocate along with Lassi that pw_gecos from the passwd struct > be added to the SRFI in the user-info record. We could call it either > full-name or full-name-field, the latter suggestion because other stuff > has been added to it in times past. 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". > We should consider if pw_shell in this struct satisfies the 80/20 rule, > or omitting it violates people's expectations. Fields in a record from > a struct are normally particularly cheap in pretty much every way. I vote to include it. As you say it's cheap, and it is a reliable source for finding out a user's login shell. (More reliable than the SHELL environment variable.) I can't think of any particular problems with it. > 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. > uname, which I noted that with the existence of uname(1) would only be > useful for automated bug reports, and John noted "Most of what's > important about it is provided in (features) in more useful form." The most useful fields in uname() are already covered by the extremely simple SRFI 112: Environment Inquiry. I suggest we leave them to that SRFI. There are more fields in uname (kernel version, etc.) but those don't contain any information that is comprehensible to a human or a program without system-dependent contextual knowledge. And on each system there are probably other, better ways to get that same information. I'll submit an SRFI about that real soon now.