>     It's not really that complex though - the subfield format is a gross
>     hack to be sure, but it has been quite uncontroversial over decades.
>     Just split at commas, take the first field and replace ampersand (if
>     any) with capitalized username. Any fields beyond the first are not
>     useful except for the now obscure finger.
>
> Not sure about that: some systems may use them internally to stash
> stuff, given that *BSD supports them.

That would indeed be a concern if we provided a facility to write the
GECOS field. But since we are only reading it, I don't see a problem
with throwing out the parts we're not sure how to use.

> How about this:  Do ampersand substitution, split on commas, return two
> values: the first part as a string, the rest as a list of strings, and
> keep the name "full-name".

Thank you for considering it. If the other subfields are desired, I
would serve them from a separate getter procedure like this:

     (user-info:full-name user-info) => first subfield of GECOS
     (user-info:personal-info user-info) => list of remaining subfields

On some OS with a better thought out user database, the personal-info
list could perhaps be an association list. Windows networks use Active
Directory for user information. It's based on LDAP. Is anyone here
familiar with what kinds of user info are stored in LDAP? I don't mean
to say we should mandate any LDAP stuff in the SRFI, but it would be
nice to give implementations a natural place to stash LDAP info if they
want to do so. Maybe Windows has an easy API to access it.

And on Unix there's NIS and LDAP too. Ugh. I'm out of my depth here.

We could also just call it something like:

     (user-info:gecos-tail user-info) => list of remaining subfields

But I secretly hope there will be some kind of distro-wide agreement to
phase out GECOS :)

> It may not be Posix, but it's always going
> to be present in /etc/passwd vel sim.

We are slowly winning you over to the
Posix-is-only-one-of-several-guidelines camp :)

> Should & substitution be done on all parts, or only the full name proper?

I don't know. I'll ask on Unix Stack Exchange.

> On the root of zoneinfo:  I think we should expect the implementer of
> SRFI 170 to figure out where it is, though we could say it's in
> /usr/share/zoneinfo with these known exceptions, and may be elsewhere.

One possibility is to readlink("/etc/localtime") and split the result at
the last occurrence of "zoneinfo", trusting that the timezones are under
some "zoneinfo" directory on all systems. However, knowing the mindset
of Unix distributors at large, we are unlikely to have such luck. They
can't even agree on whether development packages should be called "-dev"
or "-devel", let alone anything more complex. At this rate, it would be
simpler to hard-code a list of all known top-level timezones and trust
that those don't change!