[nSLUG] Plems with Linux etch
a.spanik at ns.sympatico.ca
Fri Aug 24 19:40:54 ADT 2007
On Fri, 24 Aug 2007 17:20:09 -0300
mspencer at tallships.ca (Mike Spencer) wrote:
> gnwiii quoth:
> > Please read:
> > Subject: Csh Programming Considered Harmful
> Ahem. Cough. Where's the smiley, George? 8-)
A smiley would imply a joke. The lack of real redirection in CSH and
related shells is not a joking matter.
Of course I only say that because I was a sh/ksh/bash user who found
himself suddenly admin'ing BSD boxen (default root shell tcsh) and I
spent an embarrassing amount of time trying to figure out why
"somecommand 2>&1 >/dev/null" wouldn't work.
> D.> But with all due respect, Mike stated that he used bash when root,
> D.> or when scripting (or at least, script hacking).
> Yeah, so there! ;-) Actually, I do have the O'Reilly fish book  so
> I do RTFM. I'm just more comfortable with the csh syntax.  As a rule,
> if I want to script something for which tcsh proves to be too weak,
> I'll take it to Perl or even C.
The one thing I did tend to like about CSH-derived shells is the
intuitive arithmetic. Indeed, if you've ever spent any time working
with the true-blue Bourne shell, the very idea of built-in arithmetic
constructs is something like porn.
> D.> My biggest pet peeve about tcsh: [command line editing differences]
> I do the majority of interactive tcsh command line stuff from within
> an Emacs shell buffer in order to have (effectively) infinite
> scrollback and just use emacs keystrokes to edit the command line.
> Switch to a bare xterm or console only when TERM=dumb isn't good
Have you considered screen? It supports many vi- and emacs-like
commands, provides configuration out the ying-yang, and has an
astoundingly small memory footprint, all things considered. Certainly
smaller than Emacs. And once you learn to use the scrollback buffer
and start your terminal program without a buffer, life is grand. I
especially like being able to cut/copy/paste arbitrary rectangles. The
only thing I haven't figured out how to do yet (and I suspect it's
because I have to find a way to do it through my actual containing
terminal) is copy things to the X clipboard so that I can ctrl-V paste
them in true GUI applications. I hate, hate seeeeeething hate using my
mouse when engaged in otherwise keyboard-centric activities.
> That said, maybe I should bring some examples of advanced bash
> redrection to the next install/whatever fest and see if someone will
> tutor me on how it works. I understand the basic concepts, of course,
> but, in reading, say, a .configure for a big package, I find
> redirection constructs that I just can't follow.
I totally believe that configure scripts are a joke someone came up
with many years ago that got way way way out of hand. Same for
autoconf/automake/etc. Someone out there is laughing at all of us all
And I've been using bash almost as long as you've been using CSH and I
still don't grok most of the advanced redirection examples unless I
take significant time to remind myself of how they work.
>  Since 2000. But I've had G&P Anderson's "Unix C Shell Field Guide"
> since 1989. So csh is ahead by a decade in my cognitive bricklaying.
You'll not mind if I steal the term "cognitive bricklaying" I hope,
because I'm going to anyway ;)
>  Does there really have to be a *command* named "[" (/usr/bin/[) in
> order to make the delimiters in bash work right? Gak! Why don't
> we do that with *all* the ASCII punctuation so that smileys and
> ASCII art will actually execute? And didn't /usr/bin/[ used to be
> a symlink to /usr/bin/test? But now it's not and there's no
> manpage for '[' (in my distro, anyhow).
Interesting. "man [" (or "man alias" or "man :" or "man kill" etc.)
generally brings up the "SHELL BUILTIN COMMANDS" sub-section of the
bash(1) manpage everywhere I try it. If that doesn't work and nor does
"man bashbuiltins", you could always do a "man bash" and scroll down
(or search to) "SHELL BUILTIN COMMANDS"
a.spanik at ns.sympatico.ca
More information about the nSLUG