Unix searches for commands by following what you have defined to be your PATH and executing the first command matching the string of characters you entered. So by defining your path appropriately, you may choose among different versions of the same command. For example, many implementations of Unix place programs written by the native user population into the directory /usr/local/bin. Often these programs are enhanced versions of standard Unix commands particularly suited to the local population (or so they think). Let's say someone at your site installs the GNU egrep into /usr/local/bin and you wish to use it rather than the standard egrep. To do so, simply make sure that /usr/local/bin is in your PATH before /usr/bin (where the standard egrep is kept).
Redefining your path to get one command right, say, /usr/local/bin/egrep, may cause problems when using a different command, say, diff3. Specifically, if one of your local buddies has installed a buggy version of diff3 in /usr/local/bin, it, too, will get called. To get to the standard diff3, you would have to issue the command /usr/bin/diff3 or define an alias for diff3 that calls /usr/bin/diff3.
The order of your path is also important when it comes to programs that you create. Often the default behavior is to place the current directory last in your path. There is a security reason for doing this, but it sometimes has an undesirable side effect. For example, a new user writes a short program and calls it test. After compiling, the user tries to run the program by entering the command test. The command is accepted but produces no output, so the user assumes the program is buggy. What has happened is that the system's command test comes first in the path, so it is run and not the user's program. More than one user has been frustrated by this very example.
One solution to being overruled this way is to tell the shell to use the
program in the current directory. You do this by adding a ./ to
the front of the name of the program in the local directory. In our
example the command would be ./test. This is cumbersome. A better
solution is to ignore the advice of your local system administrator
and place the current directory at the head of your PATH. This
is what we do in the sample dot files in Appendix 6 where you'll find:
PATH=.:$HOME/bin:$PATH In .profile for Korn shell. export PATH In .profile for Korn shell. set path = (. $home/bin $path) In .login for C shell.