Should ``csh be part of the System V distribution?

[Root Boy Jim]

   From: Doug Gwyn  <gwyn at brl-smoke.arpa>

   "C-like" is a joke.  Csh hardly resembles C, and to the
   extent that it does, that is not a particular advantage for
   a command language interpreter.

It is more C-like than sh or ksh you must admit. Certain modifications
to make it easier to parse (it is after all, an interpreter, not a compiler)
have been made. Substition of keywords for punctuation (`{' -> `then', etc)
allow that puntuation to have other meaning. Expression syntax is richer
and builtin.

I see no excuse for [bk]sh to have a different syntax for control flow.
It just doesn't fit in with the awk/lex/bc set of mini-languages.
It is easier to remember how csh is different from sh than to remember
what the sh syntax is, along with all the ugly `test' conditions.

Csh's problem is that it is not as general as sh. The parser is fussy
and full of ad hoc cases that often don't even work. I would love to
write a while loop on one line or redirect its output. The sh style
of redirection is definitely superior, especially the exec form.

This would be a good chance for TPC to take csh, clean it up, and
tell the world, `You see, we do Berkeley than Berkeley does Berkeley'.
However, I doubt that will happen, as the world has too much invested
in current shell scripts.

I see the need for two types of shells: one as a interactive command
interpreter, with bells (pun intended :-) and whistles galore; the
other for fast and simple command line processing called by programs,
to insulate them from the details of I/O redirection, pipe
construction, and filename globbing. In fact, with dynamic loading,
a shell might even determine whether to load the extra baggage at runtime.

	(Root Boy) Jim Cottrell	<rbj at icst-cmr.arpa>
	National Bureau of Standards
	Flamer's Hotline: (301) 975-5688
	The opinions expressed are solely my own
	and do not reflect NBS policy or agreement
	My name is in /usr/dict/words. Is yours?