Project50.Change the Command Path

Project 50. Change the Command Path

"What do I do when Bash claims it cannot find a Unix command that I know is installed?"

This project explains the environment variable PATH and shows you how Bash knows where in the file system to look for a Unix command. It shows you how to change PATH and how such changes affect the Unix manual. Project 16 shows you how to locate Unix commands manually within the file system.

Know the PATH

You may have wondered where Bash looks to find Unix commands and why sometimes, it cannot find them. First, let's explain the file-system structure as it applies to commands.

You'll find commands at the following standard locations:

• /bin/essential core commands.

• /sbin/essential, core system commands.

• /usr/bin/the rest of the vendor-supplied commands.

• /usr/sbin/the rest of the vendor-supplied system commands.

• /usr/local/bin/commands installed locally. That is, the commands that you have installed, as opposed to those that are part of the standard (vendor-supplied) Mac OS X install.

• /usr/local/sbin/system commands installed locally.

You usually expect to issue a command by typing the bare command name, such as ls, not by typing a full pathname, such as /bin/ls. Consequently, Bash requires a list of pathnames to search when given a bare command name. That's where the environment variable PATH comes in; display it, and you'll see a list of colon-separated pathnames.

$ echo $PATH /bin:/sbin:/usr/bin:/usr/sbin

Check this against the list above, and you'll notice that only the local paths are missing. An executable in any directory listed in the pathname list can be referenced by typing the bare command name. An executable outside the pathname list will not be found, unless you reference it by typing a full pathname (or change PATH, as described below).

Tip

The command type tells you where Bash will find a specific command. It's covered in detail in Project 16.

If a command of the same name exists in several of the directories listed in the pathname list, Bash will invoke the first one it encounters, searching the paths in the order in which they are listed. To invoke a different variant, use that variant's full pathname.

Recommended Search Order

The order in which pathnames are listed in PATH defines the order in which Bash conducts its search. You'll want to place the pathnames for locally installed commands (like those in /usr/local/...) toward the start of the list. In this way, if you install an alternative version of a standard Unix command, Bash will find your version first. You might also install your own private commands in ~/bin, and would place this pathname first in the list.

The default value of PATH is set in the systemwide Bash configuration file.

$ cat /etc/profile # System-wide .profile for sh(1) ... PATH="/bin:/sbin:/usr/bin:/usr/sbin" export PATH

Learn More

Project 47 covers Bash configuration files.

Change the PATH

You might want to set up a custom path for all users by changing the default PATH setting in /etc/profile. Alternatively, change just your own settings by defining a new path in ~/.profile.

Try this command; it'll fail if you are using the default pathname list.

$ xterm & -bash: xterm: command not found

A useful addition to the pathname list is the directory /usr/X11R6/bin, which would give easy access to X11 commands. You also might want to add /usr/local/bin, /usr/local/sbin and, if you have installed the developer tools, /Developer/Tools.

Edit either the global or local Bash configuration file stated above, setting the environment variable PATH to

PATH="/usr/local/bin:/usr/local/sbin:/Developer/Tools: /bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin"

Start a new Terminal session, and try to launch xterm. This time, the executable should be found.

$ declare -x DISPLAY=":0.0" $ xterm & [1] 18040

Learn More

Refer to Chapter 4 for information on Unix text editors, and see Project 55 to learn more about background jobs.

The first line is necessary to define the display device. In the second, we launch xterm, but in the background to regain immediate control of the original Terminal window.

We should also be able to refer to developer tools without the need for a full pathname.

$ cpmac usage: cpmac [-r] [-p] <source-path> <dest-path>        cpmac [-r] [-p] <source-path>... <dest-dir>

Note

X11 is an optional install. You must select the X11 package when you first install Mac OS X or add it later by performing an additional install. In either case, opt for a custom install, and select the X11 package. Also, you must be running X11, located in Applications: Utilities on the system disk, before you can execute xterm.

Add to the PATH

You might want to include your own personal Unix executables directory, such as ~/.bin, in the pathname list. This is best done by adding to the standard path rather than redefining it. Let's write such a command to your personal Bash configuration file ~/.bash_profile. Add the line shown below.

$ cat .bash_profile PATH=~/bin:$PATH:.

Now start a new Terminal session or simply source the configuration file by typing

$ source ~/.bash_profile

If we examine the new value of PATH, we should see that the directory bin in our home directory now appears at the start of the pathname list.

$ echo $PATH /Users/saruman/bin:/bin:/sbin:/usr/bin:/usr/sbin:.

Dotty PATHs

You'll notice that we also added dot to the end of the path. This trick ensures that the current directory, no matter what it is, is always in the path, affording us the luxury of typing simply

$ scriptname

to execute a script in the current directory, instead of

$ ./scriptname

Dotty PATHs and Security

Placing dot in your path has security implications.

If you were to mistype cat as car, you'd get a command not found error. However, if the current directory happened to contain an executable or script called car, you'd execute it accidentally.

There are those who rate this as a significant security risk, arguing that a malicious user might plant a harmful executable such as car, or some other common misspelling of a standard command, in a public directory that you might have set as your current working directory. Make your own judgment as to the risk versus the benefits of dotty paths.

Note that a dot at the beginning is a more serious risk. A malicious user need only plant a fake command such as ls to have you to execute it instead of the real ls.

Tcsh Shell Paths

Setting an environment variable in the Tcsh shell uses a different syntax. We might define PATH by typing

% setenv PATH "list/of/pathnames/here..."

We might add to the start and end of PATH by typing

% setenv PATH ~/bin:${PATH}:.

Know the MANPATH

The Unix manual uses PATH to search for "nearby" directories that may contain man pages. The search for man pages is made in the same order as for executables. This ensures that all commands in the pathname list have accessible man pages and that in the case of duplicate commands in different paths, the correct man page will be found.

Check the Unix manual page of the man command itself for a full explanation. The man command reads a configuration file called /usr/share/misc/man.conf.

In versions of Mac OS X before 10.4 (Tiger), the Unix manual relied on the manpath command, or the MANPATH variable, to determine the locations and search order for man pages. Its configuration settings are stored in the file /etc/manpath.config.

Note

There's no need to set the MANPATH variable.