Home > Help Files > Unix > Search path

UNIX: Search Path


			 SETTING SEARCH	PATHS
			Initializing the Shell

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".

 


Comments to consult@newton.berkeley.edu
© 1998-2008 UC Regents