From: John Cowan <xxxxxx@ccil.org>
Date: Sunday, August 11, 2019 10:58 PM

On Sun, Aug 11, 2019 at 10:35 AM <xxxxxx@ancell-ent.com> wrote:

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.

As long as we get back uids and gids from file-info, we need to be able to map them into human-readable name.
 
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.

Neutral on this one.

I perhaps jumped the gun and removed it.  When I put on my implementor's hat, it doesn't make the cut given that it's duplicates existing behavior unless you're browsing, which is a use case we agreed we don't care about supporting.

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.

It's been a loooong time since it was the username on the GECOS timesharing system <https://en.wikipedia.org/wiki/General_Comprehensive_Operating_System>

Indeed, and I know about it only because I'm a historian and because of my exposure to Original Formula Multics.  But people still might recognize "(pw_)gecos" even if they don't know the history behind it.

[ We keep pw_shell. ]
 
current-timezone, which can be picked up from the TZ environment variable, and in general deserves being part of its own SRFI.

The trouble comes when TZ isn't set, in which case you have to look at /etc/timezone, the system default timezone.  The trouble here is that it's sometimes a plain file containing the timezone name, and sometimes it's a symlink to a particular file in /usr/share/zoneinfo.  But since we have flushed the ability to read symlinks ...

You can't realize which is which by looking at the contents?  I'd be very leary of dispatching purely on whether it's a symlink or not.

Maybe it's better to bring back readlink after all.

I'm personally less keen on it because for my backup use case you need lseek to restore sparse files, and you have to know quite a bit more about a Scheme's port implementation to correctly implement it vs. the current procedures in the I/O section.

- Harold