Directories with binary files in Linux

Question

I noticed that when I install new application there are a few possible directories where the resulting binary file will be placed.

You can install with packaging manager, compile with make, easy_install for Python etc.

My $PATH looks as follows:

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

Are there some conventions or rules that determine in which directory the resulting binary (or library) should be placed?

I noticed that when you compile the source code the result is often in /usr/local/bin/. Is this the rule?

Could you write the answer that explains the Unix philosophy (design and conventions decisions) according to binaries and why is it in this way (why not to use only one directory for all binaries)

Solution 1

There is no hard and fast rule but each distribution has its own logic behind putting things where they do. Generally, /bin is used for system binaries, /usr/bin for default applications that comes with the distribution and /usr/local/bin for things that are installed outside of the normal distribution. You can add a X11 to any of those for X11 binaries – /usr/X11/bin and /usr/local/X11/bin are quite common. Some software will install in /opt as well.

This article has a more in depth explanation for things in /. And of course, wikipedia has a page.

Solution 2

In addition to @Sardathrion's answer, sbin directories are generally used for the binaries for various kinds of system management tools, low-level system applications, and often system daemons of various kinds.

For example, among sbins you will find things like /sbin/init (which controls the boot process once the kernel has finished its internal initialization), /sbin/hdparm (read and set hard disk operating parameters), /usr/sbin/cupsd (printing daemon), /usr/sbin/smartctl (read SMART data from hard disks), and so on.

The general convention is also that /usr is managed by the package manager, and /usr/local is managed by the user, or system administrator (in cases where the two are not one and the same). This has historical precedent: when disk space was expensive, /usr could be mounted read-only over the network and shared among many workstations even with systems that did not support outright network booting. Each workstation could then have its own, comparatively tiny, /usr/local, as well as possibly a (relatively lightweight) root file system (/). This distinction between /usr and /usr/local is most likely the reason why most packages default to install into /usr/local when built from source code.

Solution 3

The Filesystem Hierarchy Standard specifies where Linux distributions should place files.

bin directories contain executables intended to be used by any user, while sbin directories contain executables intended to be used only by the system administrator. sbin directories are normally only in root's $PATH.

/bin (and /sbin) contain programs that are needed early in the boot process, because /usr could be mounted on a separate partition (even though this is rare nowadasy).

/usr/bin (and /usr/sbin) contain programs that are provided by the distribution, and that are not in /bin or /sbin. On a typical system, a large majority of executables are in /usr/bin.

The /usr/local hierarchy is the realm of the administrator. The directories /lib, /bin, /sbin and /usr are normally reserved to the distribution, and generally contain only files provided by the system package manager. /usr/local (and in particular /usr/local/bin and /usr/local/sbin) are untouched by the package manager, so this is where the local administrator may place executables installed manually.

/usr/games may contain executables that are provided by the distribution and considered purely recreational. It's largely a historical survivance (a long time ago, /usr/games might be off-limits at certain times of the day, but this kind of practice — which was easy to work around anyway — has died down).

Other common executable locations on Linux system include:

• /usr/X11R6/bin or /usr/bin/X11 for X programs. The practice of separating X programs from non-X programs has died down; nowadays they all live in /usr/bin.
• /usr/bin/mh for executables of the MH email client, which manipulates emails through single-purpose shell commands (show to display a message, forw to forward a mail, …) Only MH users would put /usr/bin/mh in their $PATH.
• /opt/bin, if it exists, would contain symbolic links to applications installed in /opt.

The rules for Linux are inspired by general guidelines followed by most unix systems, but each unix variant has its own quirks. For example:

• On *BSD, / and /usr contain only the core of the distribution: basic services and applications that are maintained directly by the distribution maintainers. Third-party programs (“packages” or “ports”) are installed in /usr/local, even if they are managed by a package manager. There is no commonly-accepted separate location for programs provided by the system administrator.
• Some unix systems have no /bin directory, it's a symbolic link to /sbin or /usr/bin.
• Some systems may have extra directories containing optional package, each of which puts its own bin directory in the $PATH.
• Some systems may have extra directories which may or may not be placed on the $PATH depending on what the execution environment should be compatible with, for example /usr/bin/posix or /usr/xpg4/bin or /usr/xpg6/bin for compatibility with POSIX/Single Unix, or /usr/ucb for compatibility with legacy BSD systems.

Comments

[Martin Schröder]

A starting point for this is man hier.