From: John Cowan <xxxxxx@ccil.org>
Date: Friday, August 02, 2019 12:43 PM
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.
I'd still rather give the user the tools to avoid all that ceremony, assuming of course they're e.g. starting with a call to file-info as part of dispatching on a file as they're perhaps traversing part of the filesystem.
[ We agree, or I brought it up in my previous reply to Lassi's first reply. ]
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
Ugh. To go further on my previous reply, this is the sort of thing that's ideally compartmentalized in one or more other SRFIs.
Especially since you often want to do other date-time stuff at the same time, like subtracting and adding intervals, while allowing for a change in daylight savings time, leap years, etc. etc. ad nauseam. The newly adopted by mainline Java date time library, Joda-Time when I used it, was pretty sane to use (wrapped for Clojure).
[ We agree, or I brought it up in my previous reply to Lassi's first reply. ]
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).
I suppose we have to, given how few Schemes implement OS threads, or have done so long enough to trust that, given how Dennard scaling failing (power and speed) in the previous decade has required going "wide". Lisps have had a great performance story through their history compared to recent reinvent the wheel artifacts like Python and Ruby which you just can't make fast and efficient, we want to continue supporting that. Which was one of the primary motivations behind Clojure, which is very much competing with Scheme for mind share. And now that Scheme and Clojure governance have swapped their stories, that strongly favoring Scheme.... (Oh yeah, and Oracle buying Java, and using it to try to copyright APIs. Utterly toxic.)
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.
I'm going to give it all very serious "nit picking" analysis. The latest thoughts pertain to 3.2 I/O, the first 5 procedures that convert between ports and file descriptors.
I assume they're useful for the base SRFI in the context of a developer who's writing C native or FFI code to run in the same address space as the Scheme code, but who doesn't want to hunt around for these primitives in the implementation's code, as I am doing right now with Chibi Scheme ^_^. Vs. their being only useful for fork/exec and thus candidates to move to the process SRFI.
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.
Not sure if I made it clear, but I was planning on keeping all 4 of these functions in the base SRFI, including getting umask more for appearances sake than real need (it is ultra-trivial, no args, give back an int). Setting umask at the beginning of your code also helps protect you from making errors, plus you don't know what umask a user might be using.
The privilege-dropping and -resuming system is a footgun....
If we do this,
I'd like a decision on moving out the process stuff "soon", e.g. sometime next week if that fits everyone's schedule (it is vacation season). I think it would do a great job of partitioning the POSIX functionality we want to supply into two much more digestible meals, and I can't think of any other axis that would suffice.
the new SRFI shouldn't just be a clone, it should be a reworked high-level process control library.
Or you could do both. Especially if you expect there will be people who still want to use the low level primitives, ultra-dangerous though they may be. If these programs were written to a low level as sane as possible fork/exec SRFI standard that got widely adopted enough, it would be easier to audit and understand them. It could also make doing the higher "spawn" level SRFI easier to do, again partitioning the functionality into two more digestible bites.
Ah, the more I think about it, the better I like it. Scheme implementation gurus have to write the lower level one to interact with their implementation, while the higher level needs experts in how to least unsafely do spawn et. al. on Linux, the BSDs, etc.
Both Posix and Windows suck here....
Indeed they do, and this is very much a area I want to defer to people who know it.
[ Credit, answered in the reply to Lassi. ]
- Harold