From: John Cowan <xxxxxx@ccil.org>
Date: Monday, August 19, 2019 1:27 PM
I claim these are two separate things, and that we cleanly separate them for UNIX implementors, so they can primarily focus on the low level FFI, and simply supply the standard procedure to parse it with little or no change:
I agree. But should that procedure be documented in SRFI 170, or somewhere else? I can go either way on that, since we are now outside the domain of Posix.
I view the SRFI in its current state a "semi-standard, much more so for UNIX, basic systems programming library". We call it a (basic, now that processes are stripped out) POSIX SRFI because that quickly gets the point across. So in addition to having bog simple wrappers, and hooks into the implementation to bridge Scheme and POSIX I/O, it currently includes helpful procedures like directory-files, create-temp-file the, and call-with-temporary-file that are built straight on top of the wrappers, plus temp-file-prefix ... and these are build on top of our experience in systems programming.
We could certainly break out a SRFI and probably expand it, a "Useful Systems Programming Procedures Devised by People Who Were Probably Programming UNIX(TM) Before You Were Born" ^_^. And implementing each would require different talents ... although in that case to be consistent we would for example have the basic POSIX SRFI export termios wrappers, and put the with- or without- wrappers of those POSIX calls in the other SRFI.
In the user-info level have a "comments" field which is the raw pw_gecos field, and mention in the description that it's named the gecos field for historical reasons, and note the procedure to parse it.
I still feel strongly that the accessor should be called user-info:full-name, not user-info:comments. Granted, the result may contain more information than the full name, but I don't think that makes the accessor name significantly misleading if it is properly explained.
That certainly works for me. Or to be pedantic, some variation of full-name-and-maybe-more....
Then `parse-full-name` can take the full name and return the parsed and &-expanded information as a list of strings. (The BSD finger(1) man page confirms that the login name is titlecased before it is interpolated, and that interpolation is done in the first field only. SRFI 129, which is not part of R7RS-large, contains titlecase algorithms and data.)
[...]
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. That violates the separation principle I mention above, but there will inevitably be a lot of that with Windows coming from a completely different branch of operating system history.
I think implementations on Windows SHOULD return the full name only, rather than trying to pull other information from Active Directory. If the full name as recorded by Windows contains a comma ("John Jones, Jr."), it's probably best to remove it. I'm going to look into Cygwin's notion of the gecos field further.
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.
One more point: I want to bring back the `parent-pid` and `process-group` accessors as well as adding `session-id`. They don't fit well into my ProcessesCowan proposal, but they are harmless and trivial to implement.
Sure, and I made a point-in-time save of stuff like that before it was removed, but why don't we hold off for a while, especially since SRFI-170 can't get finalized until errors are split off, and the timespec SRFI is done.
Ah, while I'm mentioning the latter, if that timespec SRFI is supported by an implementation's import facility, could the basic timespec that's currently a pari become a record-type without causing problems?
- Harold