>From: Lassi Kortela <xxxxxx@lassi.io>
>Date: Monday, August 12, 2019 7:39 AM

>>>> 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 [group:members].  When I put
>> on my implementor's hat, it doesn't make the cut given that it
>> 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.

Scheme being a LISP (vs. e.g. Clojure being a Lisp), I vote list.

The "harm" is in demanding more effort from an implementor, it
requires the trick of supporting an array of indefinite length
at the end of a struct.

>> [ pw_gecos history. ]

>>> [ We keep pw_shell. ]

> I only now realized that Windows doesn't have an equivalent of pw_shell.

I should have double checked POSIX, it does, so:

> (Well, it kind of does....  [ And that was your final push to UNIX. ]
>
> 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.

Whenever it's not too hard, agreed.  Which probably means that a critical
path for this SRFI is e.g. your taking my Chibi Scheme implementation
of it and making as much possible work on Windows, I having given up on
it after XP.  Assuming you haven't given up on it as well.

A MacOS port would not be unwelcome, hopefully would be relatively easy
since I'm including OpenBSD in my implementation.

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

Sounds like I should add a comment to that effect in the 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.

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

Ugh, this sounds very messy.  But well within the remit of this SRFI.

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

John says it's beyond the remit of this base POSIX SRFI.  I'm adding
that for my use case of restores after a backup, people with skin in
the game only caring about restores, readlink is insufficient.

- Harold