rbj@icst-cmr.arpa (Root Boy Jim) (05/18/88)
From: Doug Gwyn <gwyn@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@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?