Re: kawa shell concept

[Helmut Eller <eller dot helmut at gmail dot com>]

* Per Bothner [2012-02-06 21:05] writes:

> 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>.
>
>    The basic Scheme function is something like:
>
>  (run keywords... "command-name" "command-options" ...)
>
>    This evaluates to a ProcessRunner result.
>
>    When output is "displayed" (as in the REPL) it is automatically forced,
>    and so the command's standard output is copied to the REPL's output.
>
>     Output to variable
>
>  (define x (run ...))
>  (define x ::string (run ...)) ;; forced
>
>     Input from string
>
>    An expression following the keyword parameter in: is evaluated to a
> string
>    and connected to the standard input of the process:
>
>  (run in: "abc" "tr" "a-z" "A-Z") --> "ABC"
>
>     Pipe
>
>  (run in: (run "command1") "command2")

How's this implemented in Java?  Is there even a JDK API to create real
pipes?

>
>     path-chars and path-bytes
>
>  (path-chars (filepath "/tmp/xxx"))
>
>    path-chars returns the contents of the path as a lazy[string].
>    path-bytes returns the contents of the path as a lazy[bytes].
>
>     Input redirection from file
>
>  (run in-file: "filename" "command")
>
>    is equivalent to:
>
>  (run in: (path-bytes (filepath "filename")) "command")
>
>     exit code
>
>    Waits for the process to exit, and returns the exit code.
>
>  (process-wait (run ...))

Would be interesting to see how one waits for multiple processes.

>
>     Using shell
>
>  (run shell: #t "ls -l")
>
>    In general (on Unix):
>
>  (run shell: #t keywords... "command-name" "command-options" ...)
>
>    is equivalent to:
>
>  (run keywords... "/bin/sh" "-c" "command-name" "command-options" ...)
>
>    Other options xs(See Python's subprocess.)
>
>    bufsize: size controls buffering.
>
>    executeable: filename
>
>    preexec_fn: procedure Call procedure in the child process just
> before the
>    child is executed. (Unix only.)

This one seems problematic on a JVM.

>    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
> process.
>    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 cant specify the program's path
> relative
>    to cwd.
>
>    env: env-map A mapping that defines the environment variables for
> the new
>    process; these are used instead of inheriting the current process
>    environment, which is the default behavior.
>
> Questions
>
>     Encoding: bytes vs chars

Should be selectable per stream.  Using the platforms default character
encoding if nothing is specified.

>     Should run be a syntax or function?

If it is a function then it would be desirable to make "command-options"
a list instead of a rest argument to avoid excessive use of apply.  It
would also be good to beef up the existing make-process and system
functions a bit before coming up with some fancy macro.

>    Should "command-name" "command-options" be self-quoting symbols or
>    strings?
>    E.g. (run /bin/ls -l) or (run "/bin/ls" "-l") ?
>    Perhaps both forms (with different names)?
>    Perhaps (run /bin/ls ,@(get-ls-options))

Probably strings.  That avoids conflicts/issues with . and : and spaces
in filenames.

>     Which keyword options?

A way to separate stdout from stderr seems to be missing.  Also what
should happen if a process terminates with non-zero exist status.
What's the exist status of a pipeline?

Helmut