Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!asuvax!noao!arizona!gudeman
From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.unix.shell
Subject: Re: separate the command language and interactive she
Message-ID: <2509@optima.cs.arizona.edu>
Date: 27 Apr 91 19:37:27 GMT
Sender: news@cs.arizona.edu
Lines: 107

In article  <419@smds.UUCP> Richard Harter writes:

]Actually I think this is an excellent idea; however there are some
]issues to be resolved.  I am going to use Lakota as a reference point
]since it was designed with this kind of usage in mind; however other
]languages such as TCL, Python, and Icon are relevant.

Just to clarify my terms: I would call sh a command language and csh a
combination of command language and interactive shell.  I wasn't
suggesting a completely different type of command language like those
mentioned above (although I think it is a good idea).  My suggestion
was just to separate the interactive part of the unix shell from the
command part.  You would run the interactive shell of your choice with
the interactive command language of your choice; for example you could
run an interactive shell that implements the csh history mechanism
with sh as your command language.

(In the following, an interactive shell is an ish and a command
language is a clang.)

]...what one
]really needs is a solid protocol for the interface between the shell
]and the command language.  Here are some of the issues that occur to
]me:
]
](a)	History recording
]Presumably the shell is responsible for history editing.  Who has the
]responsibility for capturing history?  If multiple programs (processes,
]pseudo-processes) are sharing the interpreter, can command history
]information be passed from one to another?

Features that are only useful interactively belong in the ish, and
those that are only useful in programs belong in the clang, those that
are useful in both applications are problematic.  I'd say that history
recording belongs in the ish because it is only useful interactively.
Sharing of history among different programs is entirely controlled by
the ish.  Different ishs can do different things.

](b)	Command completion
]A popular feature of some shells is command and/or file completion.
]Does this extend to commands in the shell language?  If so, how does
]the interpreter pass to the shell the list of commands to search?
](This isn't hard, but one needs a spec.)

There are a lot of things that the ish and clang might want to
communicate to each other -- this could be an argument for not
separating them.  However, I prefer to look for a way to have them
communicate without affecting other programs that aren't in on the
scheme.  Here are some skeletal ideas:

First, this assumes a line-based program.  (Programs that take over
the screen probably will not have much use for the ish).  There is an
environment variable 'ISH' that is set to the name of the interactive
shell currently controlling the terminal.  This variable is only set
by an ish that understands the protocol outlined below.  A program
that is prepared to interact with an ish will will communicate with
the ish using the protocol if ISH is set and if the output of the
program is being piped to the ish (I haven't figured out how the
program determines that).

Since all stdout of the process is being piped to the ish (so the ish
can do interactive things with it) the program can communicate with
the ish by special output lines.  Since the i/o is line-based, the
program and ish can use non-printable characters to communicate.  So
say that any text bracketed by ^A and ^B is treated as communication.
When an ish-ready program starts up, it begins by sending to stdout a
communication that specifies any relevant information.  When a program
exits or turns the ish pseudo-tty over to another program it send
relevant information to the ish.  When an ish needs filename or
command completion, it sends communication to the program.

Of course an alternative to the ^A^B hack is to have a separate pipe
between the programs and the ish for communication (stdish?), but this
means a program that is not ish-ready gets started up with an extra
file descriptor that it doesn't know what to do with.  Is that a
problem?

](c)	Processes and pseudo-processes
]A Lakota pseudo-process is implemented as part of the parent process.
]The issue here is whether the command language interpreter executes as
]part of the shell process or as a separate (cooperating process).

I don't have a preference as long as neither one actually needs the
other to operate effectively.

](d)	Environment variables
]Does the shell or the command interpreter have the responsibility for
]managing process environment variables?  What are the rules?

Hmm.  Environment variables definitely have to be part of the clang
since you need them in programs.  But the ish needs environment
variables too.  How about this: environment variables are part of the
clang.  The ish is started originally by some other program (like the
clang that reads the .login file) and inherits the environment from
that program as usual.

Since the ish doesn't spawn other processes (the clang does that) you
don't really need the ability to change general environment variables,
you only need to change things like 'history' that change the
behavior of the ish.  But I'd say that the ability to change the
behavior of the ish is part of the ish program.  Each one can provide
its own ways to effect this behavior -- and that may or may not look
like setting environment variables.
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman