The ECN No Name Newsletter is no longer being published. This is an archived issue.

A Path Primer

Dave Halsema

When you log into your ECN computer account a program known as a shell is run. A shell program acts as an interface between you and the operating system of the computer, and in general, makes life easier for you by performing such tasks as printing out your prompt, interpreting commands that are typed at this prompt, managing your environment, and hundreds of other things. There are several shell programs available at the ECN. The examples in this article will focus on two shells known as the Bourne shell and C-shell. However, note that the principles discussed are applicable to other shell programs.

All of the accounts here at the ECN are set up to run C-shell when the account is created. You must explicitly change your shell in order to use something other than C-shell. If you are unsure what shell you are using, you can find out by typing "finger " where is your login name. One of the fields displayed by finger is "Shell:" This field will contain the following for C-shell and Bourne shell:

/bin/csh = C-shell

/bin/sh = Bourne shell

A shell's environment is simply a configuration for the shell program. The environment determines how the shell program will act during its execution and is implemented by variables whose values can be read and modified by the user.

The variable that is of concern to us in this article is the PATH variable in Bourne shell and the path variable in C-shell. The name of the variable is the same for the two shells; however the letters are not capitalized in C-shell. To find out the current value of your path variable type "echo $path" if you are using C-shell and "echo $PATH" if you are using the Bourne shell.

When you type a command at your prompt it is either the name of a program stored on disk, or it is a command that your shell knows internally. These internal commands are known as shell built- ins, and the code for the shell built-in commands resides within the shell program itself. Some built-in commands for the C-shell are: alias, rehash, setenv, and hashstat. Some built-in commands for Bourne shell are: exit, export, set, and trap. Your shell looks at what you type on the command line and first checks to see if it is one of the built-in commands, and if it is, executes that built-in command.

If it is not a built-in command, the shell then checks to see if the command contains the character "/" within it. If it does, then you have entered either an absolute or relative path to the command, and the shell knows exactly where it is located. An absolute pathname is one in which the directories leading to the program are listed in order starting at the root directory and ending with the program name itself. A relative pathname is a listing of directories relative to your current directory; absolute pathnames are all relative to the root "/" directory. Relative pathnames make use of the two directory names, "." and "..". A single period represents the current directory, and the two periods represent the directory one level above the current directory. (Sometimes called the parent directory).

An example of an absolute pathname for the ls command could be /bin/ls The first "/" is the root directory. Within the root directory, there is another directory named bin. Within this directory, the executable file named ls is found. Some examples of relative pathnames are the following: ./check and ../check. In our first example the shell will try to execute the program named check in the current directory. The second example will execute the program named check in the directory one level above the current directory. Whether you type in an absolute or relative pathname, you are telling the shell exactly where the program is located, and the shell should have no problem executing it for you.

What happens if you just type "ls" at your prompt and hit the return key? What we have typed is not a shell built-in command; there is also no "/" character in our command, so it is not an absolute or a relative pathname. The shell needs to know where the ls program is located before it can be executed. This is where our path variable becomes important. The path variable is simply a list of directories in which the shell searches for commands. The path variable is initialized to a default value by the login program. (The login program is the one that asks you for your login and password). Here is the default path for machines that are running Sun's Solaris 2.x operating system:

/usr/site/bin /usr/local/bin\

/usr/opt/bin /usr/bin .

Here is the default path for all other machines:

/usr/ecn /usr/ucb /bin /usr/bin /usr/new\

/usr/local /usr/custom /usr/unsup .

Since the majority of students at this point will have computer accounts on non-Solaris machines, I will use the second path listed above in my example. Again, suppose we type "ls" at the prompt. Since ls is not a built-in command, and it is not a relative or an absolute pathname, the shell will use the path variable to determine where the ls program is located.

The first directory checked is /usr/ecn. The shell discovers that there is no executable file named ls in that directory. The same thing is true for the next directory /usr/ucb in our path. However, when our shell checks the directory /bin it does find an executable file by the name of ls. The shell immediately stops searching through our path and executes the program, /bin/ls. Suppose in this example that two programs named ls reside in the directories /bin and /usr/bin . Which ls will be executed? Since the directory /bin comes before /usr/bin in our search path, the shell will execute /bin/ls.

You will notice that the default paths provided by the login command have "." as the last directory. As previously mentioned, this represents the current working directory. It is very important to understand that placing a "." in your path can cause confusion and jeopardize the security of your computer account. If you decide to have a "." in your path, make sure it is the LAST directory in your search path. Placing the current working directory last insures that you will execute only those system programs which you intended to run instead of something out of the current directory, thus eliminating potential confusion on your part.

The easiest way for C-shell users to define their search path is to set the path variable in their .login or .cshrc file. Within one of these two files we may have the following:

set path = ( $path ~/bin )

When using C-shell, it is necessary to use spaces to separate each directory entry in the path. This statement adds the directory ~/bin to our search path. The tilde character "~" represents your home directory, thus ~/bin represents the directory named bin in your home directory. This enables you to place custom programs in your own personal bin directory, and your shell will be able to locate and execute them.

Bourne shell users can define their path by editing the file .profile and setting the variable PATH. Here is the same path we defined above for C-shell users using Bourne shell semantics.

PATH=$PATH:$HOME/bin

export PATH

Bourne shell users must separate each directory entry with a colon. The export line allows programs started by your login shell to also receive your path definition. To view this path definition, one can type "echo $PATH". Here is what it will look like for non-Solaris machines:

/usr/ecn:/usr/ucb:/bin:/usr/bin:\

/usr/new:/usr/local:/usr/custom:\

/usr/unsup::your_home_dir/bin

The current directory "." is given by a null directory entry. A null directory occurs when a directory entry is missing. In this example, the last two directory entries of our path are the current directory "." followed by our personal bin directory. To place the current working directory at the end of a search path, use a single colon at the end of your path definition.

Admittedly, very few people actually use the Bourne shell as their login shell. However, the Bourne shell is a popular choice for writing shell scripts and the method of defining a path within a shell script is the same as outlined above. The same holds true for users writing scripts with C-shell.

Lets look at another example, where I will add the directory /usr/ecn/X11 to my search path. This directory contains programs that are used under the X window system, such as xbiff, xman, and xclock. My login shell is C-shell, and I will use the default path assigned to non-Solaris machines.

Here is what I place in my .login or .cshrc file to make the modifications to my path.

set path = ( $path /usr/ecn/X11 )

Unfortunately, the one problem with the above examples is that the current working directory is still not at the end of our search path. C-shell users can overcome this problem by placing the following in either their .login or .cshrc file. As an example, I will add the directory /usr/ecn/X11 to my search path just like the above example except that the current working directory will now be set to the end of my search path.

set newpath = ""
foreach piece ($path)
    if ($piece != ".") then
       set newpath = ($newpath $piece)
    endif
end

# At this point the variable newpath
# contains the list of directories found
# in the default search path as set by the
# login program excluding the "." directory.

set path = ($newpath /usr/ecn/X11 .)

set path = ($newpath /usr/ecn/X11 ~/bin .)

Bourne shell users will find it easier to place the current working directory at the end of the search path. Again, I will add the directory /usr/ecn/X11 to the search path, while making sure that the current working directory is last.

PATH=$PATH/usr/ecn/X11:

export PATH

Lastly, there is a useful program by the name of which that I use often. At the prompt you can type "which " where is the name of a command or program. The which program will scan your search path and print the absolute pathname of the program that will be executed when you type "command". For example typing "which ls" produces a result of /bin/ls. The which program can be used to troubleshoot problems you may be having with your path definition by allowing you to check which program is being executed when you type in a command. (Note: the which program does not handle aliases correctly in some shells.)

I hope this article has been informative and useful to you. As always, I can be reached for questions and/or comments at halsema@ecn.purdue.edu.

HTML