Re: Current thoughts on pw_gecos field Lassi Kortela 19 Aug 2019 20:26 UTC
> If it's full-name, certainly. And I don't recall anything else that's standard in Windows that could be put in there, but XP was the last version of Windows for me. WinAPI has a GetUserNameEx() function. We can get any of these :) NameUnknown, NameFullyQualifiedDN, NameSamCompatible, NameDisplay, NameUniqueId, NameCanonical, NameUserPrincipal, NameCanonicalEx, NameServicePrincipal, NameDnsDomain, NameGivenName, NameSurname If we pay the price: <https://stackoverflow.com/search?q=getusernameex> > That certainly works for me. Or to be pedantic, some variation of > full-name-and-maybe-more.... I've consistently had good luck specifying "raw" variants of procedures. That tends to organize things naturally somehow. The above Windows list has NameDisplay: 'A "friendly" display name (for example, Jeff Smith).' Seeing it on that list, it feels more natural than "full name". "Full name" is vaguely similar to "fully qualified name". And displaying is the purpose of the name. After all, you can't reliably parse anything from it (not even the surname). System accounts can have anything in there (some BSD system accounts have jokes!) But display-name says what it is geared toward. Combining the above, we could have: * user-info:display-name -- NameDisplay on Windows. Ampersand-expanded first gecos subfield on Unix (unless implementor is sure they don't need to parse it on the underlying OS). * user-info:raw-display-name -- Raw gecos field on Unix. Same as normal display-name on Windows. And if the SRFI implementor does parse commas and ampersands for one reason or another, the display will just be cruddy :) People are used to getting crud on their screens anyway for any number of reasons.