7.2.1. Environment variables
7.2.1.1. General
We already mentioned a couple of environment variables, such as PATH and HOME . Until now, we only saw examples in which they serve a certain purpose to the shell. But there are many other Linux utilities that need information about you in order to do a good job.
What other information do programs need apart from paths and home directories?
A lot of programs want to know about the kind of terminal you are using; this information is stored in the TERM variable. In text mode, this will be the linux terminal emulation, in graphical mode you are likely to use xterm . Lots of programs want to know what your favorite editor is, in case they have to start an editor in a subprocess. The shell you are using is stored in the SHELL variable, the operating system type in OS and so on. A list of all variables currently defined for your session can be viewed entering the printenv command.
The environment variables are managed by the shell. As opposed to regular shell variables, environment variables are inherited by any program you start, including another shell. New processes are assigned a copy of these variables, which they can read, modify and pass on in turn to their own child processes.
There is nothing special about variable names, except that the common ones are in upper case characters by convention. You may come up with any name you want, although there are standard variables that are important enough to be the same on every Linux system, such as PATH and HOME .
7.2.1.2. Exporting variables
An individual variable's content is usually displayed using the echo command, as in these examples:
debby:~> echo $PATH
/usr/bin:/usr/sbin:/bin:/sbin:/usr/X11R6/bin:/usr/local/bin
debby:~> echo $MANPATH
/usr/man:/usr/share/man/:/usr/local/man:/usr/X11R6/man
If you want to change the content of a variable in a way that is useful to other programs, you have to export the new value from your environment into the environment that runs these programs. A common example is exporting the PATH variable. You may declare it as follows, in order to be able to play with the flight simulator software that is in /opt/FlightGear/bin :
debby:~> PATH=$PATH:/opt/FlightGear/bin
This instructs the shell to not only search programs in the current path, $PATH , but also in the additional directory /opt/FlightGear/bin .
However, as long as the new value of the PATH variable is not known to the environment, things will still not work:
debby:~> runfgfs
bash: runfgfs: command not found
Exporting variables is done using the shell built-in command export :
debby:~> export PATH
debby:~> runfgfs
--flight simulator starts--
In Bash, we normally do this in one elegant step:
export VARIABLE =value
The same technique is used for the MANPATH variable, that tells the man command where to look for compressed man pages. If new software is added to the system in new or unusual directories, the documentation for it will probably also be in an unusual directory. If you want to read the man pages for the new software, extend the MANPATH variable:
debby:~> export MANPATH=$MANPATH:/opt/FlightGear/man
debby:~> echo $MANPATH
/usr/man:/usr/share/man:/usr/local/man:/usr/X11R6/man:/opt/FlightGear/man
You can avoid retyping this command in every window you open by adding it to one of your shell setup files, see Section 7.2.2 .
7.2.1.3. Reserved variables
The following table gives an overview of the most common
* License
