> 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.

I've always done this by trying to mess with the files and coping if
that causes an error. Can't recall any programs (mine or other people's)
that check before the fact whose file something is, except for very
specialized purposes (not for access control).

getgroups() gets the full list of your own supplementary groups.

> Locale, though, pertains to things like characters, very much in the
> remit of this SRFI, but perhaps we should digest the returns?

The locale stuff is another Unix feature that always causes problems :)

The character encoding parts of those problems are hopefully solved by
the near-universal adoption of UTF-8 very soon.

The other locale settings (date, currency and number formats) - these
exist in principle, but do people actually know how to use them
correctly? I have no idea what locale I'm at most of the time. Even on
Windows, I always neglect the locale setting. I imagine most people are
similarly absent-minded about it.

The main time interaction I have with the locale settings on Unix is
when I get a baffling error message in shell that I don't know how to fix :)

> 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.

It might be good to have a lookup table built in.  Python has one
(import errno).

> And perhaps replace it someday with a perhaps daemon oriented SRFI.

There are not really many daemon-specific features in Unix that people
should actually use :) Programmers want to be l33t by using daemon(),
nohup, syslog, setuid() and stuff like that for their programs but it
usually doesn't make any sense. setuid() is the only one of those that
is occasionally useful (note: starting a process as root and then using
setuid() to _lower_ privileges if very different to a setuid-root binary
that _raises_ privileges). Mainly these techniques lead to reinventing
the wheel badly, security and reliability problems and encourage bad
sysadmin practices.

Daemontools (http://cr.yp.to/daemontools.html) plain and simply solved
the Unix daemon administration problem in 2001. Daemons stay in the
foreground and write their logs to stderr like all other programs. The
supervisor takes care of everything else. Systemd kept the same basic
approach but made it slightly better or worse, depending on who you ask.
But since programmers keep wanting to be more l33t than the next guy,
they keep promulgating their own syslog, backgrounding, access control
and resource limiting hacks.

Understanding daemontools is the sysadmin equivalent to understanding
Lisp and then listening to those endless "GC is slow and I need more
control" arguments from C programmers for decades :)

> 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....

Even on the internet there's the TCPMUX protocol :D
<https://en.wikipedia.org/wiki/TCP_Port_Service_Multiplexer> Wonder why
it's not more widely used.