In the base SRFI, add a direct single procedure that returns group-info:members, and keep user-uid, both necessary in concert with file-info to learn if you can modify a file or directory.
As noted in the document already, the only real way to know if you can do something on the file system is to try, and to be prepared to catch the exception.
Under the 80/20 rule uname should go as well, is it useful for anything more than curiosity which can be satisfied with the uname command, and automated bug reporting? That would finish off 3.8 system parameters for the base SRFI.
Agreed, flush it. Most of what's important about it is provided in (features) in more useful form.
These are even less justifiable than read-symlink per the 80/20 rule: user-login-name, file-info-regular?, file-info-block-special?, file-info-character-special?
Flush all except file-info-regular?, I'd say. Often enough you want to make sure something is not a directory or other weird thing.
I just checked, and Unix Seventh Edition, FreeBSD, and Cygwin all allocate the mode bits in exactly the same way (not surprising since they are stored on disk). They even all define the bits and masks with octal constants still! So anyone can portably decode a st_mode despite Awful Warnings about non-portability. I can't swear to IBM mainframes or Windows.
file-info-socket? and system-name belong to a networking SRFI.
Flush.
current-timezone and current-locale make no sense just by themselves.
If we have them plus posix-time (all non-portable), we can do date-time and i18n/L10n SRFIs that are otherwise completely portable. This is the right place to put them, I think.
Every function that takes a filename and also a port and/or file descriptor should be scrutinized for dropping port and/or file descriptor under the 80/20 rule,
Agreed; please scrutinize.
and I think all of 3.6 User and group database access also fails that test.
They're what we need to convert uids and gids from the file system into readable forms, which does come up. home_dir matters because there is no syscall to interpret tildes in pathnames, unfortunately.
The SRFI should be divided into a base, and break out into another SRFI everything pertaining to separate processes.
In that case we need a third SRFI for errno errors, for the same reasons as timespecs (but see below). I think a process SRFI is important if we want to encourage multi-process programs (which I consider a Good Thing).
At first glance I think that would move:
In 3.2 I/O, dup->fdes
In 3.3 File system, create-fifo
All of 3.4 Processes.
In 3.5 Process state, pid, parent-pid, process-group, set-process-group, and set-priority, and nice removes the process-object/pid argument, only affects the calling process. Not sure about the myriad get and set uid/gid; as I understand it, some are only relevant in the context of exec, but don't some set-uid or -gid program want to lower their privileges after starting?
All of 3.9 Signal system, which are signal-process and signal-process-group.
In 3.12 Terminal device control, I think open-control-tty, become-session-leader, tty-process-group, and set-tty-process-group.
Agreed in principle. I'd like to see more analysis on 3.5. Tentatively I think all of it should go except getting/setting the working directory. I often do that in programs, particularly shell scripts, for convenience rather than security. It's possible you might want to set the umask to protect your program's security from badly written modules that use 0777 or 0666 modes on file creation. But I think umask makes more sense when running an external program you don't control at all, hence as part of the process.
The privilege-dropping and -resuming system is a footgun (e.g if you don't drop the group before the user, bad things) and should be refactored to what setuid programs actually need. I'll investigate a few resources I found. But the Right Thing may be not to try to run setuid in Scheme at all, and leave that to a small outboard program that execs you, or indeed (x)inetd if all you need is to open a well-known port.
(Oh, how I miss Google Code Search! I'm now reduced to typing "purpose of <syscall>" and hoping someone on Stack Overflow has asked already.)
If we do this, the new SRFI shouldn't just be a clone, it should be a reworked high-level process control library. Both Posix and Windows suck here, though Windows may suck somewhat less (although that could just be my ignorance). The scsh manual (chapter 2) is a possibility; it's implemented in Guile and Chicken as well. I'm not a big fan of the high-level process forms, but the lower-level stuff looks plausible and implementing it involves subtle issues (e.g. a paren have to ignore SIGIN when running a child process in wait mode, or the parent will start running again, restart on an EINTR, or just die).
Thanks for doing all this work! I would like you to add your name (in preferred form) to the Authors section, marked (editor).
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgThe native charset of SMS messages supports English, French, mainland
Scandinavian languages, German, Italian, Spanish with no accents, and
GREEK SHOUTING. Everything else has to be Unicode, which means you get
only 70 16-bit characters in a text instead of 160 7-bit characters.