It is currently Mon, 27 Jun 2022 11:59:31 GMT

Author Message
 separate the command language and interactive she
In article  <4...@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
](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

](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

 Thu, 14 Oct 1993 03:37:27 GMT   
 separate the command language and interactive she

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

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.

 Thu, 14 Oct 1993 14:02:23 GMT   
 separate the command language and interactive she
I use various shells for my ``command language'' and a souped-up line
discipline for my ``interactive shell.'' I just added some of the new
interactive features to my poor man's line discipline. From pmlined's
latest README:

  You edit the current line on the status line (through stderr). Long
  lines scroll horizontally. When you press return, pmlined sends the
  line to stdout. All the usual editing characters, including ^U, ^W,
  backspace, delete, and ^V, work normally. ^A switches between this
  editing mode and the usual tty mode. In version 1.5, you also get ^H
  and ^L to move the cursor back and forth within the line, and a
  20-line editable history with ^B and ^F. In this version, ^P sets the
  prompt to whatever you've typed on the current line. Note that the
  prompt will be reset if you use a command from the history that had a
  different prompt. ^O<char> stores the current line in a macro labelled
  <char>; you invoke the program with <tab><char>. (Use ^V to enter
  special characters into the macro.) The arrow keys now work for up (^B),
  down (^F), left (^H), and right (^L).

At 400-odd lines pmlined is hardly a bloated piece of code. It doesn't
bother with multiplexing or tty handling or any system stuff; it just
reads its input, gives you an interactive display on stderr, and feeds
completed lines to your shell (typically ``pty csh'') through stdout.
It's hard to get much simpler than that!


 Fri, 15 Oct 1993 01:33:11 GMT   
 separate the command language and interactive she
In <> (David Gudeman) writes:

Sorry for injection some facts into an otherwise useful theoretical
discussion, but in 1987 (according to the copyright notice) Kazumasa
Utashiro of Software Research Associates, Inc. wrote a nice "ish"
called "fep" (for Front End Processor).  It's invocation is

fep [-emacs|-vi] clang

The option indicates which flavor of key bindings you want to use for
editing the history.  As you would expect, "fep sh" gives you a Korn
shell emulation, of sorts.

1. It Can Be Done.
2. The clang doesn't have to know about the ish.

Have a nice day,

Hans Mulder

 Mon, 18 Oct 1993 01:17:28 GMT   
 separate the command language and interactive she

There is such a thing in existence--The ash/atty combo by
Kenneth Almquist.  Ash is a sysV /bin/sh replacement that is lean
and fast, and featureful; atty is tty "front-end" that does line
editing and history.  Ash can be compiled to know about ATTY, and send
appropriate escape sequences to control it if present.

Ash will compile & run on almost any UNIX-compatible system from V7 and
Coherent to BSD.  Unfortunately, atty requires the BSD ptys, so I've
never tried it. (I have Coherent)

The pair was posted to comp.sources.unix, volume 19.  I suspect that
If I had BSD, I'd only use this pair.

David Fenyes                       
University of Texas Medical School           Houston, Texas

 Sun, 17 Oct 1993 23:59:07 GMT   
 separate the command language and interactive she
|Sorry for injection some facts into an otherwise useful theoretical
|discussion, but in 1987 (according to the copyright notice) Kazumasa
|Utashiro of Software Research Associates, Inc. wrote a nice "ish"
|called "fep" (for Front End Processor).  It's invocation is
| [...]
|1. It Can Be Done.
|2. The clang doesn't have to know about the ish.

The problem is that ideally, there are some ish-y functions which
require information that the clang has.  Completion is an example.  In
an ish that wants to do file name completion, it must know clang's
current directory.  Most of the fep-like programs I've seen do this in
some really ugly manner.

IMHO, what is needed is a good widely portable ish with a well-defined
protocol so that cooperative clangs can work well with them.

I envision something like the following:  user starts "ish -emacs fsh".
Ish advertises a communications channel, and starts a friendly sh,
which notices the communications channel.  User types "cdb
pro<ESC><ESC>", and ish passes "cdb pro" down the communication
channel (probably with some other info).  Fsh completes to "cdb
program", gives it back to ish.  User hits return, and fsh starts the
cooperating de{*filter*}, which notices the communications channel.  User
types "break fun<ESC><ESC>", down the channel it goes, fsh isn't
listening because it's waiting for cdb, but cdb completes it to "break
function", and passes it back.

Obviously, there are other details, but that's basically what I'd like
to see.  So many projects, so little time...

 Tue, 19 Oct 1993 01:10:36 GMT   
 separate the command language and interactive she
In article  <1991May02.171036.23...@sco.COM> John R. MacMillan writes:
]I envision something like the following:  user starts "ish -emacs fsh".
]Ish advertises a communications channel, and starts a friendly sh,
]which notices the communications channel.  User types "cdb
]pro<ESC><ESC>", and ish passes "cdb pro" down the communication
]channel (probably with some other info).  Fsh completes to "cdb
]program", gives it back to ish...

That is more-or-less what I had in mind.  Taking completion as an
example: each ish-ready program has a set of named things.  The user
wants to be able to type part of the name followed by some signal that
means "complete the previous name".  However, there might be several
classes of name things, and you only want to complete within the
correct class.  For example in a clang, you want seperate completion
for commands, filenames, and environment variables.

Part of this can be communicated by command-line description such as

  <command-line> ::= <command> <arg>* | "set" <var> = <arg>
  <arg> ::= "-"<char>* | "$"<var> | <file>
  path-complete <command> with "echo $path"
  path-complete <file> with "pwd"
  list-complete <var> with "variable-completion %s"

Each ish-ready program would have such a specification plus a set of
commands, (in this case just "variable-completion") that print out a
list of possible completions.  This eliminates the need for a
communication channel.

Type "set TE<ESC><ESC>" at the prompt.  The ish gathers characters
until the control sequence.  Then it looks at the specification for
this command and finds that it must use the "variable-completion" to
find the completions of this name.  It sends the string

  variable-completion TE

to the stdin of the clang which responds with


on its stdout.  The ish doesn't display this output since it is
internal communication.  Rather the ish parses it and completes
the name as far as possible, extending the user's command line to

  set TERM

The nice thing about this is that "variable-completion" is a normal
command that anyone can type, it doesn't require any special
communication apparatus.

The ish has pathname completion built in, so for command and filename
completion it would only ask the clang for its exec-path or current
directory and do its own completion.  Type "ico<ESC><ESC>".  The ish
sends the command "echo $path" to the clang which responds with the
path.  Then the ish completes the command according to the path.

These command-line descriptions can be fixed files that the ish
accesses.  The only other information the ish needs is what command is
executing, and it can get that from startup messages.  I'm beginning
to think again that a special communication channel is not needed.  If
you can get by without one then you should, since the writer of
ish-ready application shouldn't have to worry about that sort of
thing.  Is there any sort of communication that couldn't be handled by
this scheme?
                                        David Gudeman

 Wed, 20 Oct 1993 07:06:48 GMT   
 separate the command language and interactive she

Let's see.  The syntax is naive: it doesn't do quoting of any sort, so
you can't do file completion on files with special characters in it.

How about completing filenames with variables embedded: "$HOME/$a/a".

How about history completion: expand things like "!$" and "!vi".

How about glob completion: expand things like "*" and "f*".

A more serious problem: the shell isn't the only thing that
wants/needs completion.  gdb, for example, wants to do completion.

Teaching the front-end about all this gets ugly.

The simplest way to handle completion is to have a communication
channel between the front-end and the current interactive process.
(Which immediately has two problems in Unix: What's the "current
interactive process"?  How do I talk to it?  (So how do we fix Unix?))
Felix Lee

 Thu, 21 Oct 1993 14:16:25 GMT   
 separate the command language and interactive she
|Teaching the front-end about all this gets ugly.

I agree.

|The simplest way to handle completion is to have a communication
|channel between the front-end and the current interactive process.
|(Which immediately has two problems in Unix: What's the "current
|interactive process"?  How do I talk to it?  (So how do we fix Unix?))

Again, agreed.  I think your two questions are interrelated.

If we use stdin/stdout as the communications medium, it's easy,
portable, and the current interactive process is the one that is
reading the other end.  Eg. ish starts sh, sh is current.  Sh starts
gdb, so is waiting, gdb is reading, so it is current.

The big drawbacks to this mechanism are that a non-cooperative program
may just happen to look like a cooperative one on stdout, and that the
communication is either visible to the user, or must be hidden by the
programs (and again, you could accidentally hide something that just
happened to look like communication).

If this method is not acceptable, some other IPC mechanism must be
used.  Sockets on BSDish systems, and one or two of the too-numerous
SysV IPC mechanisms would seem the obvious choices.  In this case, the
cooperating processes could negotiate who the current interactive one
is over the IPC mechanism (sh relinquishes its status when starting
gdb, and gdb asserts itself as the current interactive process).

 Sun, 24 Oct 1993 03:40:48 GMT   
   [ 9 post ] 

Similar Threads

1. seperate the command language and interactive she

2. separate the command language and interactive

3. separate the command language and interactive

4. Running interactive command in C language

5. c-shell as a command language rather than a programming language

6. Command for spawning separate process?

7. Two separate MAC addresses for two separate NICS?

8. Separate keymaps for separate vt's?

9. Separate keymaps for separate vt's?

10. startup commands and interactive mode

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software