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