seperate the command language and interactive she

[Jamie Mason]

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

	I use the csh for typing commands.  I like it very much (even
though some users of larger shells (eg tcsh, bash, etc...) would find
it's history mechanism and the like rather primitive.  I find the csh to
be a nice interactive shell.  But for scripts, it should be called the
cs*HELL*.  I used to use #!/bin/csh for my shell scripts.  But there are
problems.

	Csh comes up too slowly, even with -f.  Csh sufferes major forms
of brain damage for shell programming.  For instance the 'undefined
varible' b.s. that csh barfs up and crashes your scripts.  Or the fact
that quoted inline text must escape all the returns, even inside quotes,
so an awk script embedded in a csh script must be written as awk '\
BEGIN {foo}\
/foo/ {bar}\
END   {baz} '

	There is so much csh brain damage not mentionned here that I
finally learned my lesson and started programming in /bin/sh.  Bourne
shells may lack the nice C-like syntax for control structures, but there
is one overriding advanatge to /bin/sh syntax: it is *CONSISTENT*.  There
is no silly brain damage, what works WORKS.  /bin/sh treats whitespace
consistenly (newline ~= space).  It treats quoting consistently.  And
for all the (relatively) ugly syntax (what's the most natural way to
end an if?  fi is *REAL* natural, same with esac :-), the command
language fits together in an intuitive way, without all the silly cshell
warts.

	So I could not agree more -- separate the interactive shell from
the command language.  Most of us already have, anyways.


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.  To do this in current Unices I think would be difficult.

	Oh.  OUCH!  Yeah, we will have Tcsh or BASH (!) type stuff in the
cooked mode.  TTY aliases.  I can just see an IOCTL to do it!  And
linking your own cooked mode driver into the Kernel?  I imagine it could
come in with a STREAMS module Push.  And users could load THEIR OWN CODE
INTO THE KERNEL to do it!  Ouch!  Uuuggghhh!

	* K E R N E L     B L O A T ! ! ! *

	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