Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!caen!news.cs.indiana.edu!arizona.edu!arizona!gudeman
From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.unix.shell
Subject: Re: separate the command language and interactive
Message-ID: <2593@optima.cs.arizona.edu>
Date: 30 Apr 91 06:28:25 GMT
Sender: news@cs.arizona.edu
Lines: 68

In article  <424@smds.UUCP> Richard Harter writes:
]
]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.

As I said before, I think this is a good idea, but you have to keep in
mind the conservatism of many users.  It is easier to introduce new
ideas a little bit at a time instead of all at once.  There are
already a large number of programming languages with line-oriented
interaction (Lisp and Prolog are probably the most well known).  Given
independent ish and clang, many people might find it convenient to use
an ish with one of these languages as their normal shell.

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

Yes.  The ish on a tty is like a window manager on a workstation --
who knows, it may even provide windows.  On a workstation the ish
would probably be relegated to a single window.

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

Yes, I guess you are right.  How would you go about implementing that
sort of thing giving the following possible combinations?  (1) Running
an ish and clang together that both understand the communication.  (2)
runing an ish that understands the communication with a clang that
doesn't.  (3) Running a clang that understands the communication on a
bare tty (no ish).  (4) Running an ish and clang together that both
understand the communication, where the clang invokes another program
that may or may not understand the communication (neither the ish nor
the clang can know this).

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

I assume you mean that the ish has to pass keyboard-initiated
interrupts on to the currently running child right?  As a note, the
currently running child may not be the clang, it may be any program
that doesn't take over the terminal.  I think the effect of various
keys should be up to the ish design.  Most ishes would probably use
raw mode and just translate certain keys as interupt initiators.

]All of this implies in turn that the clang must also have its own
]encapsulated interface.

In don't understand this comment.  I don't think the clang needs
anything more than to read lines from stdin and stdout and write them
to stdout -- except for communication with the ish.  What sorts of
information might this include?  And could that information be
specified somewhere besides in the actual clang?  What about a special
start-up file that tells the necessary information about the clang (or
any other other line-based program).
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman