Home > Online Help > Unix > Search Path

Search Path


Contents

  • Introduction to Paths
  • Setting the Search Path Automatically
  • Extensions tp the Search Path Mechanism

  • Introduction to Paths

    A search path is the sequence of directories where the shell looks for commands to execute. Directories usually contain normal files, but can also contain executable files, called either programs or commands. Without a search path, you could not do any real work, since the shell would never find the editor, the "ls" command, and other indispensable programs. If you write your own programs and shell scripts, or if you use new, specialized, or non-standard commands, you will need to know how to modify your search path. This writeup explains how to accom- plish this.

    By default, the C shell searches the current directory (.), then /usr/cc/bin, and finally /usr/ucb/bin. The directories /bin and /usr/bin are not normally searched. They exist, but contain only standard commands released as Version 7 Unix by Bell Labs-- not the locally provided versions.

    The search path is contained in the C shell "path" variable. Like all C shell variables, it can be referenced by placing a dollar sign in front of a name. For instance, the current search path can be printed with:

    	% echo $path
    
    The search path is also a component of the environment, which is passed from process to process, independent from the shell. You can print your environment's PATH variable with:
    	% printenv PATH
    
    The C shell's $path variable has spaces between directories, while the PATH environment variable has colons instead. The environment's PATH also uses the null string (indicated by a leading or trailing colon), rather than a period, to indicate the current directory.

    If you want to use a program in a certain directory (something in /usr/new/bin, for example), you could set your search path as follows:

    	% set path = (/usr/new/bin  $path)
    
    This will reset the C shell's $path variable by prepending /usr/new/bin to the previously defined search path. It will also make a corresponding change to the PATH environment variable. Afterwards, you would be able to use any program in /usr/new/bin, but only for the current login session. In fact, if there were a "vi" command in /usr/new/bin, and another in /usr/ucb/bin, the one in /usr/new/bin would take precedence. Directories that come first are always searched first.

    Setting paths with "$path" is recommended only for interactive use. If you have the above line in the .login file, or worse yet, in the .cshrc file, the $path variable will grow each time that file is read by the shell, and will contain redundant directory names. Eventually, when the $path becomes longer than the space allocated for it, the shell will core dump, and you will be unceremoniously logged out.


    Setting the Search Path Automatically

    A custom search path may be set automatically each time you log in, by placing the appropriate "set path" command in the ".login" file. (To learn more about the .login file, type "help login".) Here is a sample command line to set a non-standard search path:
    	set path = (. /usr/cc/bin /usr/ucb/bin /usr/new/bin)
    
    Make sure there is a space after the period, and spaces between all the directories starting with "/usr". You may want to place /usr/new/bin in front of the other /usr directories, if you want it to be searched first. But note that this is risky, as it would always give you new (experimental) versions of commands, rather than support- ed versions.

    The above line could have been placed in your ".cshrc" file, with the effect that your path would be set each time a new shell is started up. New shells are typically created for an editor escape, or for the execution of a shell script.

    The C shell offers an extremely useful metacharacter, the tilde, which lends portability to shell scripts and commands. When it appears alone, the tilde expands to the full pathname of your home directory. When it appears in front of a name, it expands to the full pathname of that account name.

    Suppose you have a directory of programs you have written, named "my- bin", hanging from your home directory. You could get the shell to search "mybin" with:

    	set mybin = ~/mybin
    	set path = (. /usr/cc/bin /usr/ucb/bin $mybin)
    
    You should set the $mybin variable first so the Bourne shell, and oth- er programs, will not get confused by the tilde in the PATH environ- ment variable.

    If there is a directory of programs somewhere on the system, say the directory "bin" in the account "eecs", then you could add that direc- tory to your search path with these commands:

    	set csbin = ~eecs/bin
    	set path = (. /usr/cc/bin /usr/ucb/bin $csbin)
    
    Again, for compatibility with the Bourne shell and other programs, it is best (though not necessary) to preset the $csbin variable.

    Now if you add a totally new program to ~/mybin, and then change out of that directory and try to use the new program, the C shell will say "Command not found." This is because the C shell keeps a hash table listing all the programs in the search path, for increased efficiency. Until you issue the command "rehash", which remakes the hash table, the C shell will not be able to find the new program.

    A hash table, in this context, is a list of programs, with an indica- tion of where they are found; it resides in memory, internal to the C shell. The hash table is made for all directories in the path except the current directory (.), which can always change. It is created at login, and remade whenever you set your path.

    Normally, the shell does a linear search of the current directory, be- fore it consults its internal hash table. For increased efficiency, you can place the dot last in the list of directories to be searched:

    	set path = (/usr/cc/bin	/usr/ucb/bin /usr/new/bin .)
    
    Then, the shell would look in the hash table before doing a linear search of the current directory, allowing programs to start up a bit faster. This is a reasonable modification, as long as you don't plan to use programs in your "." directory with the same name as those in standard system directories.

    If the path is set in the .login file, it is done once at login, and passed to subshells (for shell scripts or editor escapes) by means of the PATH from the environment. If the search path is set in the .cshrc file, the $path is reset every time a new shell is started up. Although the second method may seem less efficient, it has one advan- tage: if you execute commands over the network, the network shell reads the path from the .cshrc file, but not from the .login file.


    Extensions to the Search Path Mechanism

    On Unix A-F, some locally modified programs use search paths to locate other things besides commands. The environment's PATH variable is used to locate manual pages, help files, and include files or li- braries for C programs. The locations for these files are determined by taking the elements of the PATH which end in "bin" and replacing "bin" with the generic name of a directory, such as "man" for manual pages, "help" for help writeups, "include" for include files, and "lib" for loader libraries.

    At present the following programs have been converted to use the PATH variable to locate their files. Both "cpp" and "ld" are called by the C compiler, "cc".

    	PROGRAM		FILES LOCATED BY USING PATH
    	-------------------------------------------
    	man		man pages
    	help		help files
    	cpp		include	files
    	ld		loader libraries
    
    If you were interested in setting up manual pages for your own collec- tion of programs, you could put the programs in "bin", then make a parallel directory "man", with a subdirectory "cat1". All manual pages should be pre-formatted, and have the name of the matching pro- gram as their root, with a ".1" appended to that root. For example, if a "kwic" program resided in ~hum/bin, then its formatted manual page should be in ~hum/man/cat1/kwic.1 and its unformatted manual page might be in ~hum/man/man1/kwic.1.

    If you want to create your own help writeups, you could put them in a parallel directory "help", in files named after the topic. For exam- ple, a file named "shell" in the "help" directory will be printed by the command "help shell".