The PATH variable is just a list of directories separated by
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,
:: in the middle) means "the current directory."
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 itsand commands for which you give the complete pathname. Here's a demonstration:
setenv PATHSet PATH to null accidentally %
lsls: 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 towhichever initialization file defined your PATH variable, usually .login for C shell users or .profile for Bourne shell users:
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:
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:
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:
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. If you really need an overlapping name, you can use a to specify "the program called true in the current directory":
Here are some related articles. You can search your PATH for a command with 6.5 explains the C shell's path variable., , and . Article