> 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.