10.2.1 Simple Aliases

The simplest kind of alias is simply a new name for an old command. For example, you might want to rename the ls command as dir because you're used to DOS or VMS systems. That's easily done:

alias dir ls

dir is the new name; from now on, typing dir as a command is equivalent to typing ls. Some other commonly used aliases are:

alias la ls -a         # include "hidden" files in listings
alias lf ls -F         # show whether files are directories, etc.
alias lr ls -R         # list recursively-show directory contents
alias ri rm -i         # ask before deleting
alias mi mv -i         # ask before moving over an existing file

In a .cshrc file, the hash mark (#) means that the rest of the line is a comment. Describing your aliases can help you remember what they're for. That's an especially good idea for complicated aliases you write - like the aliases in the next section.

10.2.2 Using More Complex Aliases

Here are a few aliases that I find useful; you'll have to adapt them to your own circumstances:

alias emacs /home/src/emacs/bin/emacs                       
alias clean "rm *~ .*~ core *.bak"                          
alias vtext 'setenv EXINIT "source $HOME/.exrc.text" ; vi'  
alias vprog 'setenv EXINIT "source $HOME/.exrc.prog" ; vi'

Let's look at these aliases more closely. The emacs alias isn't anything fancy; it's just a way of remembering a long command name, without having to add another directory to your search path (8.7) for a single command. (I find long search paths aesthetically unappealing. They can also slow your system down, although the C shell uses a hash table (52.9) to speed up searching. On the other hand, it takes time to read aliases like emacs from your .cshrc file into the shell. Defining lots of aliases, instead of simply changing your search path, can delay logins and subshells (38.4). If you have a fast computer, it may not matter whether you use lots of aliases or have a long search path.)

The clean alias is great; it deletes GNU Emacs backup files and core (52.9) files (which I usually don't keep around) and other miscellany. Rather than have some complex "auto-cleaning" system that runs from cron, I just occasionally type clean in my current directory. Everyone should have an alias like this and doctor it so that it gets rid of as much junk as possible. (A lot of people, though, would tell you not to be so quick to delete your editor's backup files. Use your own judgment.)

The third and fourth aliases are a bit clever, in a primitive sort of way. You type the command vtext afile; the shell separates the commands at the semicolon and executes one after the other:

$HOME	setenv EXINIT "source $HOME/.exrc.text" vi afile

The first command sets the EXINIT environment variable (6.1); this makes vi read a particular setup file (4.9) named .exrc.text in the home directory. The second command starts vi with whatever arguments you type. You aren't limited to just one filename. You can type whatever arguments you want, including more filenames and vi options; they're all tacked on after vi. There are more graceful ways to get command-line arguments into aliases (10.3), but this does the trick when the arguments go on the end of an alias.

Note that we put this alias in quotes. Why? Because it's a compound command (setenv, then vi). We want the alias to include both stages of the command. Think about what this means if we don't put quotes around the alias definition when defining the alias:

alias vtext setenv EXINIT "source $HOME/.exrc.text" ; vi    Wrong!

The shell sees the semicolon (8.5) (a command separator) outside of quotes, so it separates the command line into two commands. The first command defines the vtext alias to run setenv, not vi. After the alias is defined, the shell runs the second command: vi with no filename. In any case, the results have nothing to do with what you want.

The way we originally defined the vtext alias, with quotes around the whole definition, is what we want. The outer quotes tell the shell to put everything into the alias definition. The semicolon in the alias will be interpreted, and separate the two commands, any time you use the alias.

Next, look at the clean alias. As with the vtext alias, this one needs to be quoted. The reason now is a bit different; the quotes prevent the shell from expanding the * wildcard immediately. That is, if you just typed:

% alias clean rm *~

the shell would expand the wildcard immediately. So if a file named foo~ is in your current directory, the clean alias will be rm foo~. That (most likely) isn't what you want; a clean alias that will only delete one particular file isn't very interesting.

So you need a way to prevent the shell from interpreting the * right now (when you define the alias); you want the shell to interpret * later, when you use the alias. There are plenty of articles in this book about quoting (8.14, 8.15), but the simplest way to write an alias that uses wildcards (or other special characters) is to put it inside of quotation marks.

10.2.3 Setting Aliases Automatically, Unsetting Aliases

Any aliases you define can be placed in your .cshrc file, so that they'll be available whenever you're using the C shell. (Note: aliases are not passed to subprocesses (2.2), so putting them in your .login file probably isn't wise.)

Some people like to use aliases to redefine UNIX commands. For instance, you could make an alias named rm that actually runs mv, moving a file to a "trashcan" directory instead of actually removing it. [1] Redefining commands can be confusing or dangerous (10.6). Still, in some cases, aliases that redefine commands can be useful.

[1] Article 23.9 shows the delete programs, a better way to do this.

To temporarily use the default rm (not your alias named rm), type a backslash (\) before the name (8.12):

% \rm filename

To use the default rm for the rest of your login session:

% unalias rm

Unless you remove the definition from .cshrc, the alias is restored the next time you log in (or the next time you create any new C shell).

A final piece of trivia: the C shell manual page tells us that aliases can be nested; that is, they can refer to other aliases. Personally, I think this would get too complicated too quickly to be very useful, so I don't do it and can't recommend it. But you can try.