Current thoughts on pw_gecos field
hga@xxxxxx
(19 Aug 2019 14:33 UTC)
|
Re: Current thoughts on pw_gecos field
John Cowan
(19 Aug 2019 18:27 UTC)
|
Re: Current thoughts on pw_gecos field Lassi Kortela (19 Aug 2019 19:09 UTC)
|
Re: Current thoughts on pw_gecos field
John Cowan
(19 Aug 2019 19:19 UTC)
|
Re: Current thoughts on pw_gecos field
Lassi Kortela
(19 Aug 2019 19:58 UTC)
|
Re: Current thoughts on pw_gecos field
hga@xxxxxx
(19 Aug 2019 19:51 UTC)
|
Re: Current thoughts on pw_gecos field
Lassi Kortela
(19 Aug 2019 20:26 UTC)
|
Re: Current thoughts on pw_gecos field
Lassi Kortela
(19 Aug 2019 20:32 UTC)
|
Re: Current thoughts on pw_gecos field Lassi Kortela 19 Aug 2019 19:09 UTC
Thanks for braving the continued GECOS saga with us Harold :) > I still feel strongly that the accessor should be called > user-info:full-name, not user-info:comments. I have to agree with this. "Comment" is so vague that it's not resilient against unforeseen extensions. Any kind of information could in principle go in a comment field. And the full name is what programmers want to get out of it. > Then `parse-full-name` can take the full name and return the > parsed and &-expanded information as a list of strings. A separate parse-full-name procedure sounds reasonable under the circu(m)stances. However, here's one more point of view: SRFI 170 implementors already deal with Unix idiosyncrasies. Even though GECOS parsing is not the same traditional kind of idiosyncrasy as select/poll and threading facilities or errno values, it is an OS idiosyncrasy nonetheless. So implementing GECOS parsing requires the same mindset (which I often suspect may be indistinguishable from masochism). > (This is known as the ice-cream koan.) Design by koan - a development process with timeless appeal. > If the system is Windows, have the user-info procedure fill in this > comments field in a manner that will be properly parsed by the > supplied procedure. I can see the rationale, but personally I would prefer any other approach. The GECOS field (which apparently would nowadays be properly named the finger field) would spread to systems that used to be free of those concerns. If Windows users can for example put commas in their full names, as is reasonable, we'd have to introduce some special behavior to mess up their names for bugward-compatibility with Unix. > I think implementations on Windows SHOULD return the full name only, > rather than trying to pull other information from Active Directory. Agreed. AD is more complex as it is likely to access the network. (I guess the get-my-full-name API can also go to the network, but is more likely to avoid it since AD is mainly used in corporate deployments and if any information is cached locally, the full name probably is.) > If > the full name as recorded by Windows contains a comma ("John Jones, > Jr."), it's probably best to remove it. For porting full names to Unix? I wouldn't worry about that since SRFI 170 does not define any procedures to write passwd entries. And Scheme strings have no trouble with commas. > I'm going to look into Cygwin's notion of the gecos field further. Nice. I missed that.