>>     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.
>>
> 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 agree with this reasoning, though also don't see great harm in
including it. We need to split it though, and decide whether to use a
list or a vector.

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

I only now realized that Windows doesn't have an equivalent of pw_shell.
(Well, it kind of does - in Windows parlance, the "shell" is the GUI
window manager, and you can in principle replace the standard shell, or
at least parts of it, through obscure partially documented means. I
tried as a kid. It didn't work very well, which was the final impetus
for me to install Unix where you can explore and customize everything. I
think companies like Stardock have built a business on
reverse-engineering that stuff and actually making it work.)

I realize this is billed as a Posix SRFI, but I continue to advocate for
cross-OS portability wherever possible. Otherwise we have to write
separate Windows SRFIs at some point.

But (user-info:login-shell) could just return #f on Windows. I don't see
a problem with that.

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

Hmm. Just looked at /etc on my Mac, and it's not clear how to portably
parse the symlink path. Mine is
"/var/db/timezone/zoneinfo/Europe/Helsinki" so you can get the desired
"Europe/Helsinki" by taking the last two components. But there are many
timezones that have only one component, and many that have three.

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

I don't quite understand what you mean. Is readlink() harmful somehow,
or you just don't see a useful application for it in a Scheme program?