Csh alias philosophy and short command names

[Andrew Burt]

Someday, when I have nothing to do for a very long time, I'm going to
drag out my old ideas and implement them.  Like windows for vi.

While I've been twidling with the history editor alias, I thought about
the little note in csh(1) BUGS:

> Alias substitution is most often used to clumsily simulate shell
> procedures; shell procedures should be provided rather than aliases.

In principle I agree with this; indeed, I have a number of little
(Bourne) scripts of the form "exec foo -my_favorite_options $*".  On
the other hand, there are a lot of things that you want done to your
current csh: setting or unsetting environment or shell variables,
making or deleting aliases, changing directories, sourcing files,
using/abusing history, job control, etc.  Csh scripts are also slow to
start up, no doubt because of all the aliases I have...  Yet it's nice
to use csh constructs instead of sh sometimes.

So I thought: wouldn't it be nice if there was another form of file,
call it a "source file" ("sourcable file"? "macro script"?  "in-line
script"?) which has these properties:

	1)  It sits somewhere on your $path like a normal executable file;
	2)  It looks and feels like a shell script;
	3)  The csh 'sources's it when it sees it, instead of forking and
		reading it.

I propose the characters "#@" begin such a file, parallel to "#!" for
an exec'able one.  The csh already has to check for # at the beginning
to see if it's a csh script, so #@ isn't much harder.  It already knows
how to source a file.  All we need is to get the two together.

Is there any interest in this?


On the matter of short command names.  I, for one, like single
character abbreviations for the most common commands: l for ls, m for
more, h for history, and so on.  On top of that I have the programmable
function keys on my terminal set to the most common ones of these
(|m<CR> for instance).  They save time.  They save finger stress.  They
are more accurate.  (Granted a slip and 'rn' (for readnews) becomes
'rm'; but with no arguments nothing terrible happens.  Admittedly you
have to watch for these sorts of possible slips.  But I maintain that
they happen far less often than a typo in a long command name,
particularly when you're tired.)

Someone suggested here that people who like short names should just
learn to type faster.  Given that I type in the neighborhood of 110
wpm, I doubt I could ever type "readnews" faster than "rn".  440 wpm
would be nice, sure, but...

Furthermore, computers are supposed to save you effort, not require you
to learn to type faster.

It's not really a question of how fast I type it.  Frankly the time
doesn't bother me.  What does is that commonly performed operations
should be lengthy to write.  You don't see anyone going around writing
"three plus three" over "3 + 3" do you?

When there IS a better way to do something, why should I stick with the
worse way on the grounds that someone looking over my shoulder might
understand better?  (At that, I don't have to stop typing to say,
"rn means readnews".)

The philosophy I practice is that any command I execute interactively
SHOULD be short to type.  Anything I put in a script should be written
out completely.  It's the same difference between talking casually with
friends using your own personal phrases and presenting a technical proposal
before a group of non-technical salespeople, bureaucrats, or investors.
While you're logged in to your own account, doing your own work, the rules
are off --  if you like typing "blt" for "whopper with cheese, no
mayo" I say more power to you.

-- 
Andrew Burt
Sigma Design, Inc.
{allegra,amd,hao,ucbvax}!nbires!koala!aburt