Below is the current state of my ideas for
"Kawa shell" support. Nothing is implemented so far.
Note this integrates with how lazy values are handled. If you
evaluate a (run ...) in a REPL, the output from the command is
"printed" to the repl output. Likewise, you can use the output
whenever a string (or a bytevector) is expected. No need for
special `quotes`. It would help to have an expanded string literal
syntax that supports embedded expressions. (I have a number of goals
for string literals, which makes it non-trivial.)
I'll probably implement something in this vein after 1.12 is released.
I'm uncertain about command names, option names (keywords), macro
vs procedure (probably both), handling Unix's byte vs text ambiguity,
etc etc, but I'm comfortable with the basic concept.
Running programs - Shell-like control of processes
We define a new Scheme process type implemented using a class
ProcessRunner , which extends Lazy<CharSequence>.
preexec_fn: procedure Call procedure in the child process just
child is executed. (Unix only.)
close_fds: #f causes all file descriptors except 0, 1 and 2 to be closed
before the child process is executed. (Unix only). Or, on Windows, if
close_fds is true then no handles will be inherited by the child
Note that on Windows, you cannot set close_fds to true and also redirect
the standard handles by setting stdin, stdout or stderr.
cwd: path-or-string the child's current directory will be changed to cwd
before it is executed. Note that this directory is not considered when
searching the executable, so you can’t specify the program's path
env: env-map A mapping that defines the environment variables for
process; these are used instead of inheriting the current process
environment, which is the default behavior.
Encoding: bytes vs chars
Should run be a syntax or function?
Should "command-name" "command-options" be self-quoting symbols or
E.g. (run /bin/ls -l) or (run "/bin/ls" "-l") ?
Perhaps both forms (with different names)?
Perhaps (run /bin/ls ,@(get-ls-options))