From: John Cowan <xxxxxx@ccil.org>
Date: Friday, August 02, 2019 3:44 PM
Oops, I left out of my first insomnia inspired message removing *all* of 3.6, User and group database access, that was why I later added back a direct group-info:members procedure.
Still thinking about this. I continue to think that because stat() exposes uids and gids, there needs to be a way to convert them to the strings we all know and love.
See below on the browsing other people's accounts. You need to know if the uid and gid returned by stat is one you can mess with, for which a direct version of group-info:members suffices, but if the uid is someone else's, or the gid not in your set? And of course you don't have to ask about uid/gid 0, the former of which I use in my testing.
Except now that you point it out, we should also include a single direct call that returns the home directory,
And sets it. Lots of programs are greatly simplified if they can set the working directory.
Well, yes, and we already have that. And e.g. directory-files without a directory argument uses the working directory, of course calling that procedure to get it (just finished all that yesterday).
Unless any of you can think of sufficient 80/20 reasons to browse other people's accounts, or find out who's in X group, etc.??
Not I.
It strikes me as beyond the remit of these SRFIs, this is not for system administrators, whereas that was in the remit of scsh.
Especially with John's suggestion to keep file-info-regular?, I'm thinking of doing this in an inverse fashion, only providing predicates for the file system objects that are relevant to the putative user of this SRFI, i.e. regular files and directories.
I think that makes sense: regular-file? and directory?.
Exactly. Anything else is "here be dragons".
It's a *colossal* can of worms, my last Lisp project in anger, a Clojure website for a non-profit I was volunteering for a few years ago, had to deal with [time zones], but only the US ones. I haven't even [find] a POSIX way to return the current time zone as a string, although I haven't looked very hard yet.
Can't be done, though /etc/timezone is an approximation. But come to think of it, the *user's* notion of the current timezone is and should be simply the TZ variable. So flush current-timezone.
Done ^_^!
Locale, though, pertains to things like characters, very much in the remit of this SRFI, but perhaps we should digest the returns?
[ The never ending fun of time zones. I can still remember my astonishment when I learned as a kid there were ones based on the half hour. ]
That's a bit messy to do portably as we're doing it now, seems the strategy is to make them high numbers. A problem this current POSIX SRFI has is that it has to use the official ones, so errno-error will return a sane string.
I think Lassi meant that idea only for Scheme-level exceptions like "can't open input file" and making it possible to pull the errno out of that, not to *supply* arbitrary errno values to arbitrary user exceptions.
I'm for that, including as mentioned before a convenience procedure to map from errno to that system's "E<whatever>" flag as a string.
[...]
We *could* view giving them setuid etc. calls in this base SRFI to use after doing high privilege stuff as encouraging them to go down this dark path.
Just so. Flush it all.
And perhaps replace it someday with a perhaps daemon oriented SRFI.
I can certainly see people doing that sanely. We do after all live in a world being taken over by systemd, I'd take a Scheme daemon over that any day.
I wouldn't.
I didn't say either was ideal ... just pointing out the revealed preferences of today. And of course once upon a time there was the Chaosnet, which had string rather than integer "ports" (on UNIX they would fire off a copy of a program by the same name), and Lisp Machines provided an EVAL....
[...]
Eh, sure. "Harold Ancell"
You're an editor, make the patch yourself!
Heh, I will.
- Harold