jrich@devnet4.hac.com (john richardson) (12/07/88)
In article <754@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >In article <1457@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: > >>If you're going to write a csh script, >>you're better off prefacing it with the line >>#!/bin/csh -f > >Indeed you are. You're even better off not writing Csh scripts. and then... >Well, everything is subject to debate. Has there been a past discussion of writing scripts for csh vs. sh? I see some advantages both ways: CSH: 2X faster (on the only benchmark we attempted) more builtins, less process generation (i.e., test, basename) :r,:e,:t suffixes to variables we are committed to Berkeley software so csh is portable enough I use csh for interactive work SH: trap statement "| while read x" construct easy stderr redirection portable to Berkeley and ATT installations John Richardson jrich@devnet4.hac.com Hughes Aircraft Company, Fullerton, Ca. (714) 732-5588 Subject to the usual disclaimers as well as all failings normally associated with the efforts of man.
guy@auspex.UUCP (Guy Harris) (12/11/88)
>CSH: > 2X faster (on the only benchmark we attempted) Err, umm, it's been *slower* on the things I tried; of course, the Bourne shell in question was an S5 Bourne shell, so it had things like "echo" and "test"/"[" built in (and may have just generally been faster). >SH: > portable to Berkeley and ATT installations That's the main benefit I see, and is the high-order bit for me.
ok@quintus.uucp (Richard A. O'Keefe) (12/12/88)
In article <114@gsgpyr.hac.com> jrich@devnet4.UUCP (john richardson) writes: >In article <754@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >>Indeed you are. You're even better off not writing Csh scripts. >Has there been a past discussion of writing scripts for csh vs. sh? I love the C-shell for interactive work, and feel as though I'm in a straitjacket when I have to use the Bourne shell. But to quote from the BUGS section of the manual page for csh(1): Quoting conventions are contradictory and confusing. Although robust enough for general use, adventures into the esoteric periphery of the C-Shell may reveal unexpected quirks. That's rather a damning confession.
jacobson@gamma.eecs.nwu.edu (Dan Jacobson) (12/18/88)
[Originally I planed to respond to John Richardson's e-mail by e-mail,
but I thought I might share my golden keystrokes with the community.]
I use tcsh (Ohio-state's) and ksh for interactive work, sh for scripts.
Doesn't the Geneva Convention say you must provide your users with
shells with command line editing (e.g. a la emacs)? I turn in fright
when faced with the prospect of typing into csh or sh for interactive
work without the protection of at least a (GNU) emacs shell window,
lest I make a typo and have to type the whole line over.
Csh's "!" history substitutions are a lot of cruft to me, now that
command line editing shells are available. Try "set histchars" to
turn it off.
Tcsh is quite flexible. You can define each key individually. In ksh
I believe you choose between the (given) emacs or vi, etc. key
definition sets. Tcsh also has one touch file and command name
expansion; ksh file name expansion is hardwired(?) to ESC * .
The tcsh prompt I give to all new accounts is packed with info: time,
1 letter hostname and current directory are achieved with:
set prompt="%S%t `/bin/expr $HOST : '\(.\)'`:%c>%s "
which gives:
10:57pm g:~> (but in reverse video)
You have to go thru major contortions to do most of this fancy
prompting with ksh.
My tcsh prompt also sometimes has: root's "#", "screen" (a terminal
emulator by Oliver Laumann) window number, and shell level depth.
Actually I'm waiting for GNU's "Bourne again shell" (what will it
have?).
My interactive commands, most not being multiline, would be the same
in all the shells mentioned, mostly. True, the csh family's (csh,
tcsh) "repeat", "@" etc. commands are useful. BSD users see their sh
scripts with "test" calls run slower than their csh scripts with
built-in (e.g. "if (-e file) command") calls because "test" is not
built-in in BSD's sh and instead lives in /bin/test (linked to "/bin/[" !).
I have been burned by csh's limitations on piping into loops,
manipulating standard output and error, etc, and generally think sh is
more robust. In sh you get to play with many file descriptors and
traps, etc.
Portability is very important to me. I don't think I'm forcing myself
to use a less flexible shell for portability's sake. I would still
use sh, portable or not.
If I were to write a csh script, I wouldn't use tcsh instead. I don't
usually need the interactive advantages of tcsh in a script, and csh
would be more portable.
Well, that's the last of my effort for shell wars... please debate
this amongst yourselves. Now on to other wars, e.g. "notes" (boo) vs.
"rn" (yea!) vs. ....
Dan Jacobson
--
jacobson@eecs.nwu.edu or {oddjob,gargoyle,att,...}!nucsrl!jacobson