[nSLUG] Plems with Linux etch

Aaron Spanik 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 [1] so
> I do RTFM.  I'm just more comfortable with the csh syntax. [2] 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
> enough. 

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
the time.

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.

> [1] 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 ;)

> [2] 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

Aaron Spanik
a.spanik at ns.sympatico.ca

More information about the nSLUG mailing list