Handout 3

The PATH Environment Variable

Of all the environment variables, the PATH and TERM 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. The empty entry:: means "the current directory."

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

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 build-in commands and commands for which you give the complete pathnname. Here's a demonstration:

% setenv PATH Set PATH to null aceiderltally % ls: ls: Command not found.
Needless to say, this can be very frustrating--especially if you can't figure out whats going on. There are a couple of easy fixes. The easiest is just to log out and log back in again. (logout is a builtin 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 whichever initialization file defined your PATHvariable, usually .login for C shell users or .profile for Bourne shell users:

% source ~/.login $ . .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 prohlem 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 some thing like this:

% printenv PATH /bin:/usr/local:/usr/ucb:/usr/bin::/home/joedokes/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 cur rent directory and your private bin directory will override the standard commands. However, that's not recommended; it's a well-known security hole.

Setting Your Search Path

Your search path controls what directories--and in what order--the shell searches for external commands. You can set a search path that takes effect every time you log in by editing your shell setup file. You might also want to change the path temporarily.

Setting Path in Shell Setup Files

To change the "default" search path used every time you log in, edit the PATH= . . . line in your .profile file or the set path= (...) line in your .cshrc or .login file.

Add the absolute path of the directory to the path. You have a Choice:

You can put the directory at the end of your path. (I think that's the beSt idea unless you know exactly what you're doing.) Then, commands in the directories you add will be used only if they have unique names that aren't found anywhere else in the path. You can check that with a command like which.
If you put the pathname close to the start of the path, before standard system directories like /bin, then commands in the directory you add will be used instead of system commands with the same name. That lets you replace commands that don't work the way you want with your own version.

When you log in, as your shell starts, before your setup files are read, your system probably has already set a default search path for you. Your system administrator can change that path. If your system has a default path, you should think about using it as part of your path--ask your administrator.

To do that, include the variable $PATH or $path as you set your path. For example, to add your bin directory at the end of the system path, use one of the following lines:

set path=($path ~/bin) C shell PATH=$PATH:$HOME/bin Bourne shell
For the Bourne and Korn shells, load the updated PATH by typing the command:

$ . .profile
For the C shell, type one of these commands, depending on which file you changed:

% source .cshrc % source .login
Changing Path on the Command Line

As you work, you might need to add a directory to your path temporarily. Use the same path setting com mand you'd use in a shell setup file:

% set path=(~/xxx/alpha-test $path) C shell $ PATH=$HOME/xxx/alpha-test:$PATH Bourne shell $ export PATH

* portions from here.