>From: Lassi Kortela <xxxxxx@lassi.io>
>Date: Sunday, August 11, 2019 10:10 AM

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

I hang on to your every word ^_^.

R7RS has SRFI-98's (get-environment-variable name), but per a check
just now I don't think any previous Scheme standard has one.  So it
looks like I should add mention of the above, but specifying both
these sources and "(get-environment-variable "USER")".

> [ Windows. ]

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

I don't think there's a positive payoff in the suggested proliferation
of SRFIs.  They're isolated, but they still require jumping down to
the world of C, and might as well be bundled with this base POSIX SRFI.

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

They're very useful at this base POSIX SRFI level for e.g. logging, so
I think they should stay here, and have the processes SRFI(s) require
at least some specific subset of procedures in this SRFI.

> [ Various, including the gecos passwd struct field. ]

- Harold