Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!sgi!shinobu!odin!thestepchild!rhartman
From: rhartman@thestepchild.sgi.com (Robert Hartman)
Newsgroups: comp.unix.shell
Subject: Re: seperate the command language and interactive she
Message-ID: <1991Apr23.174627.21446@odin.corp.sgi.com>
Date: 23 Apr 91 17:46:27 GMT
References: <2219@optima.cs.arizona.edu> <585@lysator.liu.se> <1991Apr22.210153.16143@gpu.utcs.utoronto.ca>
Sender: news@odin.corp.sgi.com (Net News)
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 49

In article <1991Apr22.210153.16143@gpu.utcs.utoronto.ca> jmason@gpu.utcs.utoronto.ca (Jamie Mason) writes:
>gudeman@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@lysator.liu.se> bellman@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