Entirely distinct from the pathname documented above
(I know that's an E2 faux paus) by Wicker808 is the
concept of the search path used in Unix and other
systems to locate the program that you have requested to
run.
A Unix command line interpreter (aka a shell) uses the
search path to find the program, unless it is one of the commands
that that shell implements itself. The search path is found in
the environment under the well-known name PATH,
and consists of a colon-delimited list of pathnames (each of which
should refer to a directory). The shell looks for the program in
each of these directories, starting with the first and working its
way through the list, until it finds an executable file with that name,
and attempts to execute it. Whether it is successful or not, the
search ends there.
A user's initial path is set by the system login procedure, and
generally includes directories such as /bin, /usr/bin,
and others which contain the standard programs provided with the system.
Thus, you can use the command date to query the system clock,
rather than explicitly requesting /bin/date. This is not only
more convenient, but allows for some variations in the location of
standard programs among different Unix and
Unix-like operating systems.
It is common for a user's login profile to add more pathnames
to the system-supplied value; these are usually appended, to ensure
that a standard program name indeed refers to the standard program, and
not another program with the same name.
The pathnames listed in $PATH may be relative or
absolute. However, relative pathnames are discouraged, because of
the ambiguity. Thus, for security reasons, a program that gives you
a shell with elevated privilege (e.g., sudo) will generally either
filter relative pathnames out of the path that it provides to the
child shell, or will provide it an entirely new path referring only
to system-supplied directories.
The PATH variable is also used by the POSIX.1
functions execlp and execvp, which then accept only
a simple filename, rather than a pathname, from their caller as the name
of the program to execute. Standard Unix shells do the search themselves
rather than using these functions, because of optimizations they do.
(See the hash command in Bourne and compatible shells.)
A comment on one point in Wicker808's very nice writeup above
about pathnames. The names . and ..
are not actually treated as special names by Unix itself
(though I expect they probably are by MS-DOS);
the . that refers to the current directory is an
actual entry and is a link to the directory that contains it. Similarly,
.. is also an entry referring to another directory.
They are, however, added to a directory when it is created by
mkdir, and rmdir, which requires a
directory to be empty in order to remove it, nonetheless allows it to
contain these two entries.