From: John Cowan <xxxxxx@ccil.org>
Date: Monday, August 12, 2019 9:42 AM
(user-info:full-name user-info) => first subfield of GECOS
(user-info:personal-info user-info) => list of remaining subfields
Works for me, except that I really, really want to keep the name "gecos" out of the spec, except as an explanatory comment.
Agreed on all, the description can say both that these record fields are derived from the pw_gecos struct member, split ... ah ha ha, we need to add for the benefit of implementors the parsing rules and/or genetic Scheme code to parse the raw pw_gecos field.
[ Today I Learned (TIL) favouriteDrink is an ISO standard! I remain
a Padlipsky fan. ]
Echoing Lassi above, I'm going to strongly argue [ scrounging the filesystem of N different Linux and BSD distributions ] is *fantastically* beyond the remit of a SRFI-170 implementor.
Actually, what's really needed is the timezone *root*, since the date-time SRFI needs to be able to find the timezone files themselves. They could be almost anywhere on Windows, which does not provide them standard (but they are available with a Java or Python installation and can be installed stand-alone if need be). So flush current-timezone.
It'll stay flushed, but it sounds like for the date-time SRFI you'd like SRFI-170 to provide a pointer to the timezone files, which I suppose is practical if you seriously narrow the requirements to a few major Linux distribution families, the BSDs, and ... Apple doesn't like Java at all, what does it do for timezones? It's not Python unfriendly, though. Once given the root, can the date-time SRFI then be expected to open and parse them?
On non-windows non-MacOS, can the timezone files be found with a sufficiently clever brute force "find" of, say, /etc, /usr, and /usr/local?? As an implementation suggestion, maybe then persistently stash it, and only retry if the stashed value is revealed by file-info to be gone?
How do we also find out what timezone we're in??
- Harold