Re: Remaining things to remove mostly per the 80/20 rule hga@xxxxxx 12 Aug 2019 12:08 UTC
>From: Lassi Kortela <xxxxxx@lassi.io> >Date: Monday, August 12, 2019 6:52 AM > [ On the various ways to get the username, etc. ] >>> 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. Urk! Right you are: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/pwd.h.html That's an argument for not including it in this base *POSIX* SRFI, especially when combined with the complexity of what it might contain as you've exhaustively documented for us. If we do, I currently advocate using the two nouns "comment" and "gecos", one for its name, the other in the description, I'm not particular on which for which. >>>> 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. See my previous comment on read-link being insufficient for backups, and for getenv we should add a requirement that either you're using an R7RSsmall Scheme or implement SRFI 98 from which it got get-environment-variable, since we're assuming you have such a procedure so that you can query your PATH. - Harold