Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!ficc!peter From: peter@ficc.uu.net (Peter da Silva) Newsgroups: comp.unix.wizards Subject: Re: csh problem involving nested ifs? Message-ID: <5016@ficc.uu.net> Date: 14 Jul 89 21:14:08 GMT References: <20243@adm.BRL.MIL> Organization: Xenix Support, FICC Lines: 51 Might I make a request. Would people who post news *AND* send mail please *SAY SO*? Anyway, I bitched about how crummy CSH is for scripts... In article <20243@adm.BRL.MIL>, rbj@dsys.ncsl.nist.gov (Root Boy Jim) writes: > I disagree. CSH is much more natural to use than SH. The constructs are > more natural. The constructs are more conventional, but they sure don't match UNIX filter semantics very well. What do you mean by "natural"? > In csh, I don't have to resort to `expr' and `test' > because these are builtin. In SH I don't have to worry about my control structures screwing up, because they're parsed instead of being implemented as commands. CSH control structures remind me more of assembler macros. > The only things I see SH is good for are: > 1) portability - sh exists everywhere > 2) trivial scripts - starts faster > 3) complex file redirection - but how often do you do 3> anyway? Not often, but I do 2> quite a bit. > 4) shell fns - neat > 5) piping to `for' and `while' - but how often? (piping, redirecting, etc...) All the time. This construct: generate_a_list_of_file_names | while read FNAME do do_something_with FNAME done is second nature. And it's impossible in csh without massive inconvenience. By comparison, having TEST and EXPR builtin is a minor optimisation. > Of course, newer SH's and KSH help quite a bit. For interactive use, maybe. I still prefer CSH history. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | Th-th-th-that's all folks... Personal: peter@sugar.hackercorp.com. `-_-' | -- Mel Blanc Quote: Have you hugged your wolf today? 'U` | May 30 1908 - Jul 10 1989