Email list hosting service & mailing list manager

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.