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 11:52 UTC

>     (getenv "USER") is the other possible route. Forcing users to
>     pick one of those two manual routes instead of having an abstract
>     (user-login-name) procedure makes things more explicit.
>
> But also more stupid.  I'm not sure what to do here after all.  You'll
> always get an answer (on actual Posix systems), even if it isn't the
> answer the user actually wants.

There's nothing stupid about (user-info:name (user-info (user-uid))) in
my book. It reads naturally and clearly shows how it maps to the OS
facilities. Are you opposed to it?

>     We could also put all the user/group database procedures in their own
>     SRFI. I think they are pretty well isolated from other OS interfaces.
>
> -1, for the reason I gave above: interpreting file-info entries.

That is a good argument.

>     Yeah, it's pretty much the "crud that doesn't fit anywhere else" field
>     :D I can't think of a good name for it either. One more possibility is
>     "comment field".
>
> It's a full name 99% of the time nowadays.

Not true. It may be a full name for 99% of passwd entries, but 99% of
systems are definitely not devoid of entries using commas/ampersands.
Linux routinely makes passwd entries that use commas, and the BSDs ship
with passwd entries that use ampersands. Also check my survey: most
systems say in their documentation that commas and/or ampersands are
recognized.

If we serve the raw GECOS field as "full-name", that claim will often be
incorrect. If we serve it by the name "gecos", that name doesn't mean
anything on non-Unix operating systems (whereas full-name probably has
natural equivalents on most OSes). FWIW, POSIX doesn't even mandate
having a gecos field at all.

>      > current-timezone, which can be picked up from the TZ environment
>      > variable, and in general deserves being part of its own SRFI.
>
>     Agree that it should go into a date and time SRFI.
>
> -1.  I want date/time to be fully portable, no dependencies on the
> current anything except the current TAI-UTC table, which is
> unavoidable.  See TimeAdvancedCowan.  See also my previous post for the
> issue with TZ.

You're right - it is a good principle to isolate a minimal OS interface.
In that case, I would be in favor of providing readlink and getenv (not
necessarily in the same SRFI). They are more generally useful.