Configuring unix programs¶
Options¶
A program on unix has access to the whole command line the user entered
to run it. In addition to arguments specifying e.g. which files to
operate on, many programs accept options specifying how to operate. So,
for example, giving a path as an argument to ls tells it where
to list, while giving the word -l to ls tells it to
print a ‘long’ listing with more detail. (You can imagine it would be
tricky to deal with a file named -l. There are ways to deal with
that ambiguity, but it’s easier just to give files unambiguous names.)
By convention, an option starts with a hyphen, as in -l. Each
program is free to handle its command line however it wants, but there
are some patterns, such as -v usually being the way to make a
program more verbose. Some options require parameters, which usually
follow the option as the next word on the command line; for example, to
specify an output file name to gcc, you use -o file.
To allow for clearer names and more possible options, some programs have
‘long’ options. For example, -h (a ‘short’ option) might
also be available as --help. When a long option takes a parameter,
sometimes it comes next as with a short option, like --color
auto, but it is usually also possible to pack them together with an
equals sign as in --color=auto.
Since short options flags are only one letter each, most programs allow
you to combine them in a single word. For example, to get ls
to show a long listing (-l) of all files (-a) one can
run ls -a -l or combine them into ls -al.
Aliases¶
If you type e.g. ls -alF so often that you want a shorter,
easier-to-remember way to type it, you can use a shell alias. In
bash, use the alias command.
alias ll='ls -alF'
From that point on, ll, when used as a command in that shell, will
mean the same as ls -alF. Aliases are deliberately limited—they
don’t really work in shell scripts, and the way they expand isn’t very
flexible. They are mostly for creating new command-ish words that run
programs with some default options you usually want to use when you are
working at the command line.
If you always want to use a particular way of invoking a program, you
can alias it over itself. For example, many people have an alias like
ls='ls --color=auto' in order to see colorful output by default,
whenever they use ls. (If you find the colors difficult to
read and wish ls would just use normal text, now you know
the culprit. Read on.)
You can view all of your current aliases by running alias
with no arguments. You can remove an alias wish unalias,
e.g. unalias ll. Aliases only persist as long as the shell,
so if you stop the shell and run another one, such as by logging out
and returning later, you would need to set up all your aliases again.
To make them persistent, you can use another configuration technique:
a run control file.
Configuration files¶
For configuration that requires more detail, or would be tedious to
specify every time you run a program, many programs read a particular
file as they start up and adjust based on what it says. Such a file
might be called an initialization file, startup file, configuration file,
run control (‘rc’) file, etc. If no such file exists, that’s usually
fine and the program just uses its defaults. Often a program will look in
more than one place for a potential rc file, such as the current working
directory, the user’s home directory, and/or a system-wide configuration
directory. The name of an rc file usually starts with a dot .,
so ls will hide it by default, so the collection of rc files
in your home directory are often called your ‘dotfiles’.
Every time bash runs, for example, it runs the script in
~/.bashrc if it exists. That’s the place to put any commands you
want to run every time you run your shell, such as an alias you want
to make persistent, or a way you like to set up your prompt. System
administrators usually provide you with a default .bashrc with
a bunch of configuration you might appreciate but are free to customize.
The documentation for a program will tell you where it looks for
rc files and what to put in them; for example, vim uses
.vimrc, emacs uses .emacs, git uses
a whole .git subdirectory, gdb uses .gdbinit,
make uses Makefile in the current working directory,
etc.
Following the unix philosophy, configuration files are expected to be easy to read and write as a human with a text editor.