6.4 The PATH Environment Variable

Of all the environment variables, the PATH and TERM (5.10) variables are the most important. The others are often great conveniences; but PATH and TERM can make your life miserable if they get screwed up.

The PATH variable is just a list of directories separated by colon (:) characters. The shell searches through these directories in order whenever it needs to find a command. So, if you want to execute commands in /bin, /usr/bin, /usr/local, the current directory, and your personal bin directory, you would put a line like the one below in your .login file. An empty entry (: as the first or last character, or :: in the middle) means "the current directory."

$HOME/bin	setenv PATH /bin:/usr/bin:/usr/local::$HOME/bin

Article 8.7 explains more about setting the path.

The most common problem with PATH is that, somehow, it gets deleted. This usually happens if you try to change PATH and do so incorrectly. When PATH is deleted, your shell can only find its built-in commands (1.10) and commands for which you give the complete pathname. Here's a demonstration:

% setenv PATH   Set PATH to null accidentally
% ls
ls: Command not found.

Needless to say, this can be very frustrating - especially if you can't figure out what's going on. There are a couple of easy fixes. The easiest is just to log out and log back in again. (logout is a built-in C shell command, so you won't have trouble finding it. If you get an error message like "Not login shell," try exit instead.) Another fix is to read (44.23) whichever initialization file defined your PATH variable, usually .login for C shell users or .profile for Bourne shell users:

% source ~/.login
$ . $HOME/.profile

This will almost certainly give you some of your path back; the problem is that a lot of initialization files merely add a few "private" directories to a system-wide default path. In this case, just execute the system-wide initialization files first (if your system has them). Their pathnames vary:

% source /usr/lib/Cshrc
% source /usr/lib/Login
% source ~/.login

The other common PATH problem is that users sometimes can't find the commands they want. This happens most often when someone writes a new shell script with the same name as a standard UNIX command - say, true. He or she tries to execute it and can't; in fact, all that happens is:

% true
%

After staring at the script for a long time, the user sometimes gets the right idea: the script is fine, it's the path that's wrong. The PATH variable will look something like this:

% printenv PATH
/bin:/usr/local:/usr/ucb:/usr/bin::/home/mkl/bin

The shell searches the PATH in order; therefore, it finds the system's standard true command before seeing the new one. The new command never gets a chance. You could fix this problem by putting the current directory and $HOME/bin at the head of the search path, in which case, commands in the current directory and your private bin directory will override the standard commands. However, that's not recommended; it's a well-known security hole.

So what is recommended? Nothing much, except: if you write shell scripts or other programs, give them names that are different from the standard UNIX utilities (44.21). If you really need an overlapping name, you can use a relative pathname (1.21) to specify "the program called true in the current directory":

% ./true

Here are some related articles. You can search your PATH for a command with which (50.8), findcmd (16.10), and whereiz (4.10). Article 6.5 explains the C shell's path variable.