The C shells, ksh and bash have an "alias" facility that lets you define abbreviations for commonly used commands. Aliases can get very complicated, so we'll give just an introduction here. We'll use the csh alias syntax here; article 10.4 shows bash and ksh .
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.
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.
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.
-
, ,