separate the command language and interactive she

Richard Harter rh at smds.UUCP
Sun Apr 28 16:02:23 AEST 1991


In article <2509 at optima.cs.arizona.edu>, gudeman at cs.arizona.edu (David Gudeman) writes:

... A number of comments on my comment which I am going to draw on
but now quote directly.  First of all, some terms:

> Just to clarify my terms: I would call sh a command language and csh a
> combination of command language and interactive shell...

David introduces the terms ish for interactive shell and clang for the
command language.  He wasn't thinking in terms of anything radically
different from sh as the clang; in my view one should keep this possibility
carefully in mind from the beginning.  David's dividing line is a little
loose but the general notion is that the interactive features belong
in the ish and command execution belongs in the clang.  He remarks that
there is assumption of a line oriented interface involved here.

On this matter it seems reasonable that (a) the clang is line oriented
and that (b) it can either operate standalone or take its input from the
ish.  There is an implication here that the clang is a servant of the
ish; i.e. an ish can select a clang but a clang cannot select an ish.
(Except as a subprocess.)

Howabout stdout?  One gets the feeling that stdout should go through
the ish, i.e. all output of the clang and its subprocesses are piped
back to the ish.  This all implies (I think) that the ish and the clang
are separate processes with the clang being started by the ish.  Since
the clang is a child that should resolve environment variable issues
shouldn't it?  Following this line we have three units

The ish:  It talks to the terminal and, as far as interactive action
goes, can be whatever you like.  It doesn't execute OS commands; its
command syntax or window widgets or whatever are its responsibility.
All terminal IO ends up going through it.

The clang:  It executes as a standalone command processor.  Its input
comes from stdin and goes to stdout and stderr; what happens to them
is none of its business.

The interface:  It is encapsulated in the ish.  It starts the clang
process and handles passing I/O back and forth.  David suggests using
control characters for communication of special commands.  Offhand I
don't like this kind of notion; it's probably better not to build in
assumptions like that.  Wouldn't it be better to have a separate
communications path.

Oddly enough the ish process never goes anywhere; i.e. cd and pwd
are executed by the clang.  Another point is that the ish will need
some special commands to set its own environment variables and to do
clang selection.  Also one has to take care of interrupts, i.e. if 
one issues an interrupt to the ish it has to trap it and pass it to
the clang with the requirement that (a) if the clang is executing
it accept the interrupt or (b) if it is executing a subprocess the
interrupt be passed to the subprocess.

All of this implies in turn that the clang must also have its own
encapsulated interface.
-- 
Richard Harter, Software Maintenance and Development Systems, Inc.
Net address: jjmhome!smds!rh Phone: 508-369-7398 
US Mail: SMDS Inc., PO Box 555, Concord MA 01742
This sentence no verb.  This sentence short.  This signature done.



More information about the Comp.unix.shell mailing list