Remaining things to remove mostly per the 80/20 rule hga@xxxxxx 11 Aug 2019 14:35 UTC
Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela 11 Aug 2019 15:10 UTC
Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela 11 Aug 2019 15:15 UTC
gecos field naming (was Re: Remaining things to remove mostly per the 80/20 rule) hga@xxxxxx 11 Aug 2019 15:28 UTC
Re: gecos field naming (was Re: Remaining things to remove mostly per the 80/20 rule) Lassi Kortela 11 Aug 2019 15:48 UTC
Re: gecos field naming (was Re: Remaining things to remove mostly per the 80/20 rule) Lassi Kortela 11 Aug 2019 16:02 UTC
gecos parser implementation Lassi Kortela 11 Aug 2019 17:30 UTC
Re: gecos parser implementation John Cowan 12 Aug 2019 04:06 UTC
Re: gecos field naming (was Re: Remaining things to remove mostly per the 80/20 rule) Lassi Kortela 11 Aug 2019 16:32 UTC
Re: Remaining things to remove mostly per the 80/20 rule hga@xxxxxx 11 Aug 2019 19:27 UTC
Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela 12 Aug 2019 12:02 UTC
Re: Remaining things to remove mostly per the 80/20 rule John Cowan 12 Aug 2019 04:04 UTC
Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela 12 Aug 2019 11:52 UTC
Re: Remaining things to remove mostly per the 80/20 rule hga@xxxxxx 12 Aug 2019 12:08 UTC
Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela 12 Aug 2019 12:20 UTC
Re: Remaining things to remove mostly per the 80/20 rule John Cowan 12 Aug 2019 13:14 UTC
Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela 12 Aug 2019 13:44 UTC
Timezone files Lassi Kortela 12 Aug 2019 14:00 UTC
Re: Remaining things to remove mostly per the 80/20 rule hga@xxxxxx 12 Aug 2019 14:07 UTC
Re: Remaining things to remove mostly per the 80/20 rule John Cowan 12 Aug 2019 14:42 UTC
Re: Remaining things to remove mostly per the 80/20 rule hga@xxxxxx 12 Aug 2019 15:08 UTC
Re: Remaining things to remove mostly per the 80/20 rule John Cowan 12 Aug 2019 16:19 UTC
What is your timezone??? (was Re: Remaining things to remove mostly per the 80/20 rule) hga@xxxxxx 12 Aug 2019 20:49 UTC
Re: What is your timezone??? (was Re: Remaining things to remove mostly per the 80/20 rule) Göran Weinholt 12 Aug 2019 21:53 UTC
Re: What is your timezone??? (was Re: Remaining things to remove mostly per the 80/20 rule) hga@xxxxxx 12 Aug 2019 22:06 UTC
Re: What is your timezone??? (was Re: Remaining things to remove mostly per the 80/20 rule) John Cowan 12 Aug 2019 22:18 UTC
GECOS field parsing Lassi Kortela 17 Aug 2019 08:51 UTC
Re: GECOS field parsing Lassi Kortela 17 Aug 2019 09:11 UTC
Re: GECOS field parsing Lassi Kortela 17 Aug 2019 09:16 UTC
Re: GECOS field parsing Lassi Kortela 17 Aug 2019 09:35 UTC
Re: GECOS field parsing Lassi Kortela 17 Aug 2019 09:55 UTC
Re: Remaining things to remove mostly per the 80/20 rule hga@xxxxxx 12 Aug 2019 12:34 UTC
Re: Remaining things to remove mostly per the 80/20 rule John Cowan 12 Aug 2019 03:58 UTC
Re: Remaining things to remove mostly per the 80/20 rule hga@xxxxxx 12 Aug 2019 11:52 UTC
Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela 12 Aug 2019 12:39 UTC
Re: Remaining things to remove mostly per the 80/20 rule hga@xxxxxx 12 Aug 2019 13:03 UTC

Re: Remaining things to remove mostly per the 80/20 rule Lassi Kortela 12 Aug 2019 13:44 UTC

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