The Unix PATH environment variable specified the operating system personality.

On Unix, the PATH environment variable effectively specified what "personality" the operating system had.

On MS/PC/DR-DOS, length limitations in the command interpreter meant that one could not have a PATH environment variable value longer than some 120 characters. (The operating system itself allowed longer; this was an artefact of the command interpreters themselves not permitting command lines longer than that to be entered. Famously, Rex Conn's 4DOS allowed longer command lines, and longer values for the PATH environment variable to be directly entered without resorting to script tricks.) On Unix, shells were nowhere near as constrained, and PATH variable values could look like this: 

# PATH sets the initial shell PATH variable
#
#PATH=/usr/bin:/etc:/bin:/boot/grub:/boot/grup/bin:/boot/solaris/bin:/sbin:\
/usr/openwin/bin:/usr/5bin://usr/X11/bin:/usr/apache/bin:/usr/apache2/bin:\
/usr/appserver/bin:/usr/ccs/bin:/usr/dt/bin:/usr/j2se/bin:usr/local/bin:\
/usr/oasys/bin:/usr/pgadmin3/bin:/usr/proc/bin:/usr/sadm/bin:\
/usr/sadm/admin/bin:/usr/sadm/sysadm/bin:/usr/sbin:/usr/sfw/bin:\
/usr/sfw/i386-sun-solaris2.10/bin:/usr/sfw/sbin:/usr/snadm/bin:\
/usr/sunvts/bin:/usr/ucb:/usr/ucb:/usr/vmsys/bin:/usr/xpg4/bin:\
/usr/xpg6/bin

— login.dfl. Sun Microsystems, Inc.. 2004-06-25.

One part of the modern model in Unix-imitators is that everything goes into one giant directory, be it Daniel J. Bernstein's /command or Arch Linux's /usr/bin. This of course causes all of the well-known and usual headaches with different commands named the same thing. An example of one such command name shared by multiple commands is fastboot (which in other models would be distinguished by being in either bin/ or sbin/).

But that wasn't the model then. The model then was a whole load of command directories. What subset of them one chose to have listed in the value of the PATH environment variable, and in what order, determined the personality of the operating system that one saw.

If you thought that GNU ls versus BSD ls, and the different ways in which you tell them things like when and when not to use colour, was a lot to handle, there was a far greater range of personalities of the ls command in the commercial Unices, some (but not all) of which were covered by their ls manual pages:

The Illumos ls manual page illustrates this to an extent, although BSD compatibility is no longer called out.

The command search path could, and to an extent still can, include things such as:

/bin and /usr/bin
the traditional, pre-dating formal standardization, general toolsets; from a post-formal-standardization viewpoint, commands that conform to the System V Interface Definition and the X/Open Portability Guide version 3
/sbin and /usr/sbin
system administration tools; usually things here are stuff that was never standardized, because manufacturers did not universally agree when it came to system administration toolsets, the whole issue was deferred for later by the standardization process, and "later" never actually arrived
/etc and /usr/etc
more system administration tools (Yes, Virginia; executables once went in /etc.)
/5bin and /usr/5bin
System V (i.e. 5) compatibility directory with AT&T Unix System 5 compatible tools
/usr/ucb
UCB (i.e. BSD) compatibility directory with BSD-compatible tools
/usr/mbin
multi-byte character set capable variants of /usr/bin tools
/usr/rbin
tools made available by an administrator to some "restricted" shells
/usr/lbin
locally-installed tools, a precursor of /usr/local/bin
/usr/amdahl/bin and /usr/sun/bin
operating system vendor tools, more generally taking the form of /usr/${OEM}/bin and from which a parallel can be drawn to /usr/local/bin
/usr/dt/bin and /usr/openwin/bin
Common Desktop Environment and OpenWindows executables, respectively
/usr/games
games
/usr/ccs/bin
various developer tools
/usr/xpg4/bin
the directory with commands that behave in the ways dictated by the X/Open Portability Guide issue 4
/usr/xpg6/bin
the directory with commands that behave in the ways dictated by the notional X/Open Portability Guide issue 6, more properly known as POSIX.1:2001 or the Single Unix Specification version 3
/opt/sfw/bin
created by installing a CD of additional utilities from Sun, now known as the SunFreeware Companion CD
/opt/csw/bin
OpenCSW and Blastwave tools
/opt/SUNWspro/bin
commands from the Sun Workshop (now known as Oracle Developer Studio) tool suite, SUNW being Sun's (original) stock exchange ticker code and spro denoting the old product name SunPro
/usr/local/bin
stuff provided by third parties who do not use an /opt subdirectory or CSW

The order of the directories in the search path is important when more than one version of a command exists. Such effects come into play most frequently when both the BSD and the System V versions of commands are available on a system. In this case you should put the directory holding the versions you want to you use first in your search path.

— Æleen Frisch (2002). Essential System Administration. 3rd edition. O'Reilly. ISBN 9780596550493.

Sun/Oracle operating systems, and their open source derivatives, were at their height perhaps the most extreme examples of such multiple personality operating systems. (Oracle has since chucked several of these directories, including /usr/ucb and /usr/ccs, away.) But some of the aforegiven are from AIX and others. /usr/amdahl/bin is from UTS, for example.

What program one ran from a given command name depended from what personality one was choosing. The idea that there was, and must be, only one program for any given command name was daft. After all, differentiating commands of the same names was what PATH was for.

The (post-2005, ksh93q) AT&T Korn shell's mechanism for enabling extra built-in commands, the inclusion of /opt/ast/bin in the value of PATH, ties in with the idea that one is expected to use PATH to control personality. This is the /usr/${OEM}/bin pattern, with ast standing for AT&T Software Technology.

To an extent, this idea survives to this day. The "standard PATH", obtainable from the getconf PATH command or the _CS_PATH parameter to the confstr() library function, is notionally the value for the PATH environment variable that enables access to all of the Single Unix Specification's "standard shell and utilities" without explicitly supplying pathnames for them. It is, effectively, the "Standard Unix" personality value for PATH on any given system.

On operating systems that have taken the Bernstein approach, such as Debian Linux, this path is just /bin:/usr/bin or even solely /usr/bin. (On Debian Linux, there are no standard utilities in /usr/sbin, which rather contains things such as agetty, ldconfig, hwinfo, and tarcat.) On other operating systems, in contrast, the "Standard Unix" personality is composed from more directories. NetBSD uses /usr/bin:/bin:/usr/sbin:/sbin:/usr/pkg/bin:/usr/pkg/sbin:/usr/local/bin:/usr/local/sbin for example; and OpenBSD /usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin.

Further reading

© Copyright 2018,2025 Jonathan de Boyne Pollard. "Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp is preserved.