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.
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.
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.
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?.
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 them, but only the US ones. I haven't even
found 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. Luckily, we can bootstrap a full implementation of timezones using the binary data files in /usr/share/zoneinfo. It's not there on Windows, but every copy of Java, Ruby, Python, etc. plusave individual apps (each their own copy, of course, it's Windows) that don't want to expose people to the *severe* limitations of Windows timezones. Or we can just have people download them from <
https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz>. (WinZip and 7-Zip can extract tarballs.)
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.
More serious thought resulting in a separate SRFI that can be used by
*lots* of other SRFIs and code sounds like a capital idea to me.
Still undecided.
Which I use religiously in my /etc/fstab files, and OpenBSD does so by
default. But all that said, *we* can't prevent someone from setting
their binary set-uid root.
Well, only if they have root already; that's one reason why chown() requires privilege (though historically it had more to do with disc quotas, preventing you from busting your quota by chown-ing files to your neighbor who never gets near filling his quota).
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.
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. There's simply too much to audit, unless your Scheme is GNU Mes; not only the program, but the whole implementation would have to be audited Gcc and clang have bugs, but overall they should be trusted much more than any Scheme implementation.
Eh, sure. "Harold Ancell"
You're an editor, make the patch yourself!
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgI marvel at the creature: so secret and so sly as he is, to come sporting
in the pool before our very window. Does he think that Men sleep without
watch all night? --Faramir