Re: kawa shell concept

[Per Bothner <per at bothner dot com>]

On 02/07/2012 01:04 AM, Helmut Eller wrote:

Thanks for good questions!

> >      Pipe
> >
> >   (run in: (run "command1") "command2")
>
> How's this implemented in Java?  Is there even a JDK API to create real
> pipes?

The default (and initial) implementation would just use a helper thread.
It reads from the output stream of command1, and writes to the input
stream of command2.  Do you know of any problems (like risk of deadlock)
doing it this way?

For Unix we could use JNI to create the pipe, if we think it's worth it.

> >      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.

My intent was not to wait for all the processes of a pipe-line -
just the one actually returned by the argument expression.
The idea is that run returns some kind of KawaProcess object,
which is a wrapper around a java.lang.Process.  So process-wait
just calls Process#waitFor.

> >     preexec_fn: procedure Call procedure in the child process just
> > before the
> >     child is executed. (Unix only.)
>
> This one seems problematic on a JVM.

True - even in an implementation that uses a lot of JNI, this feature
might be difficult to specify and implement in a safe way.

> > Questions
> >
> >      Encoding: bytes vs chars
>
> Should be selectable per stream.  Using the platforms default character
> encoding if nothing is specified.

The tricky part is whether the output and inputs are strings or bytevectors.
I think the right way to think of input and output as being "really"
byte vectors/streams but with special conversion and printing behavior so
they auto-convert to/from strings/text-streams.

Once you've figured out when/how the bytevector/string conversions happen,
then you need to figure out which encoding to use.  Using a dynamic variable
(parameter) that defaults to the default platform encoding seems plausible.

> >      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.

Worth considering, though I'm thinking about a more general
"argument-splicing" feature.

> >     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.

I tend to agree.  Though that macro form of run might allow symbols
*or* strings, and you could you unquote for run-time expressions.

> >      Which keyword options?
>
> A way to separate stdout from stderr seems to be missing.

That's not mentioned, but my idea was that in addition to
the in-file option you also have out-file and err-file options
to allow redirection.  (If out-file is specified, then the
returned string would be empty - or void.)

> Also what
> should happen if a process terminates with non-zero exist status.
> What's the exist status of a pipeline?

Yes, those are a bit messy.  My thinking is that a process that
terminates with a non-zero exit status by default throws an exception.
process-wait would disable throwing the exception.

Where things get a little weird is we might have partial output (written
to the console, or redirected to a file, or passed to the next stage in
a pipeline) and *then* throw an exception.  This is because not only
is the result from run a lazy string, but it can also be delivered
piecemeal.  I think this is ok, but some experimentation is needed.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/