Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!news.cs.indiana.edu!arizona.edu!arizona!gudeman
Newsgroups: comp.unix.shell
Subject: seperate the command language and interactive she
Message-ID: <2219@optima.cs.arizona.edu>
From: gudeman@cs.arizona.edu (David Gudeman)
Date: 20 Apr 91 17:31:21 GMT
Sender: news@cs.arizona.edu
Lines: 38

Maybe I'm missing something, but it seems to me that many of the Unix
shells combine two seperable functions: the command language and the
interactive shell.  Is there some advantage to this?  It seems to me
that there would be several advantages to seperating them.

First, by "command language" I mean the functionality of parsing the
command lines and invoking programs.  By "interactive shell" I mean
command-line editing and history mechanisms.  Filename globing and
process control are probably best considered part of the command
language (but I'm not sure about that).

I can think of the following advantages to seperating these two
functionalities:

(1) users would have more options.  They would not have to pick the
shell that gives them the best command-line editing even though they
don't like the control structure syntax.  Of course you can partly get
around that problem now by using different shells for interactive vs.
script purposes, but that is not ideal.

(2) the features of the interactive shell could be used for other
programs.  For example, the history mechanism could have different
history lists for different prompts, and every program with a
recognizable prompt could be used with the exact same history
mechanism and command-line editing as the shell.  And those other
programs would not have to implement interactive functions (as many
do).

(3) related to (2), programs that present virtual terminals (like
xterm and emacs) could have a complete window-editing environment
without having to load those functions for the shell as well.

(4) the command language program could be smaller, possibly giving
faster startup for system() calls.
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman