3.4 Processes:
The other two [spawn/spawn-path mode] values cause the procedure to return immediately with an unspecified object.
And that seems to be the case for file-spawn, which may or may not bee a good thing. If it's not a SRFI defined process object, why return anything?? Or should we say a bit more about it being system dependent, maybe imply it might be usable for debugging? It seems to be a major omission to not allow the following process status and manipulation procedures access to the child process when the fork/exec dance allows it, and posix_spawn()/-spawnp() return the child process id through an argument pointer, and if your system doesn't have them, fork/exec.
> The spawn-path variant searches the directories in the value of the environment variable PATH. A path search is not performed if the program name contains a slash character — it is used directly. So a prog like "bin/prog" always executes the program bin/prog in the current working directory.
So if a slash character is submitted to spawn-path, it works like spawn? If so, should submitting such raise an error?
Both of these procedures may flush buffered output before creating the next process.
Should we strengthen that to "should flush"? Ditto for fork?
file-spawn should have something appended to it to make it self-documenting like "-edit" or "-view". Could also be specified to try to use EDITOR or VISUAL, perhaps first, which are mentioned in POSIX in the introduction of a list, "It is unwise to conflict with certain variables that are frequently exported by widely used command interpreters and applications:". With a further recourse to the almost universal "less" and "more" programs. Then "cat" for sure, but that could be impolite, perhaps only allow it if the file is small?
Defaulting to an editor sounds more useful, or the SRFI could have procedures for each, or it could default to one and take an optional argument to do the other. It shouldn't take an argument to specify anything more specific, since that's so system dependent.
Besides backwards compatibility with scsh, why does fork allow the option of calling a thunk? Requiring passing a thunk through your FFI seems to be an unnecessary burden on new implementations when fork() has no arguments.
Shouldn't exec and exec-path take the same optional config argument that spawn and spawn-path do? We really need to be able to specify arg0, and I'd assume env as well. If so, definitely rename to execute and execute-path.
Should fork be listed before exec and exec-path, since that's such a canonical ordering of their use?
3.4.1 Process objects:
"proc" in the procedure names seems to be an unnecessarily short and potentially confusing contraction of "process-object".
See above about the "unspecified" objects the spawn procedures return.
Should the description text imply they might also be usable for debugging?
Could, probably should add a kill procedure for process objects/pids....
3.10 Time
Should the timespec format be defined before any of the procedures, and then move the section at the end that starts with "You can convert...." up there?
3.11 Environment variables, exec-path-list:
This variable contains the contents of the PATH environment variable as a list of strings, where each string contains a single directory pathname.... On Windows, the pathnames are separated by semicolons rather than by colons.
Since it's a list of strings, shouldn't this difference between UNIX based and Windows systems be invisible?
3.12 Terminal device control
The seconds time granularity of with-raw-mode is awfully high for human interaction use. Change to milliseconds in the spec, with a note that nothing better than seconds is guaranteed?
In the description of open-control-tty, why is SRFI in "If the SRFI process already has a control terminal..."? That's the only use of SRFI qualifying process.
- Harold