seperate the command language and interactive she

[Robert Hartman]

In article <1991Apr22.210153.16143 at gpu.utcs.utoronto.ca> jmason at gpu.utcs.utoronto.ca (Jamie Mason) writes:
>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.
>
>	I use the csh for typing commands.  I like it very much ...
> ... But for scripts, it should be called the
>cs*HELL*.  ...
>
>	So I could not agree more -- separate the interactive shell from
>the command language.  Most of us already have, anyways.

I'm not sure that I agree with this, even though I too use csh for
typing and sh for scripts--but only if ksh isn't available.  While in
csh I often use foreach loops and other control structures.  One of the
most productive design principles in UNIX (and one which I wish had
been even more consistently applied) is that every utility is in some
sense a programming language.

So, what I'd propose instead is that any interactive command interface
function as a strict superset of its command language.  Also, I'd like
to ask that any and all command languages be Turing equivalent and
support an arbitrary-length name space.  troff is a good example of
what not to do.

>In article <585 at lysator.liu.se> bellman at lysator.liu.se (Thomas Bellman) writes:
>>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....

>	Yes, I think it isa good idea, but I think it should be done by a
>USER LEVEL process.  Either the controlling process on a PTY, or
>somehting like the emacs shell window.  Please, PLEASE, *PLEASE* don't
>put BASH or EMACS into the Kernel.  Please!  :-)
>
>Jamie  ...  Segmentation fault (core dumped)
>Written On  Monday, April 22, 1991  at  04:59:50pm EDT

I agree.  Actually, once the kernel has the descriptor open for a tty,
why should it care how the keystrokes get filtered prior to a RETURN?
I don't see how allowing a user-selected editor to process pending input
lines could be a security or segmentation problem.  Can someone enlighten
me if it is?

Thanks,

-r