seperate the command language and interactive she

Thomas Bellman bellman at lysator.liu.se
Mon Apr 22 02:49:23 AEST 1991


gudeman at cs.arizona.edu (David Gudeman) writes:

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

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

> (2) the features of the interactive shell could be used for other
> programs.  [...]

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

I think this would be good.  The proper way to do it, would be to have
a smarter cooked mode AND let the user load his own cooked mode
library.  To do this in current Unices I think would be difficult.

The only problem is if you want some key interact specially with the
underlying program.  E g in BASH, you can press ESC ctrl-e to expand
all variables, aliases and backquote expressions in the line, so you
can edit the result.  I don't have any ideas for how to do this, but
it's something I would like to do.

Personally, I don't like the idea of having different historys for
different programs, since I often do something in one program, and
then want to use what I wrote there, in the shell.  But that could
easily be remedied by switching to another cooked mode library.


--
Thomas Bellman,  Lysator Computer Club   !  "Make Love - Nicht Wahr"
          Linkoping University, Sweden   !  "Too much of a good thing is
e-mail:         Bellman at Lysator.LiU.Se   !   WONDERFUL."     -- Mae West



More information about the Comp.unix.shell mailing list