Most executable files should be installed in this directory. (See Section 4.2.2, “sbindir: System management commands” and Section 4.2.3, “libexecdir: Programs not meant to be run directly by a human” for the exceptions.)

Mutable and machine-specific files may not be installed in this directory, even if they are executable. Subdirectories may not be created within bindir.

Files that are not executable may not be installed in this directory, even if they are in some sense “programs.” All files installed in bindir must be recognizable by the system call execve as executable, assuming the CPU and operating system support execution of that type of program. Software compliant with this specification must not ever rely on the fallback behavior of the C library functions execlp and execvp when execve fails with code ENOEXEC.

The default value of bindir is $(exec_prefix)/bin.

Executable files that are exclusively useful to the system administrator (e.g. fsck), and executables that implement system services (e.g. sshd), should be installed in this directory. The word “exclusively” in the previous sentence is intentional. If there is any plausible situation where an unprivileged user might want to use a program, it should be placed in bindir, not sbindir.

All the requirements on files installed in bindir also apply to files installed in sbindir.

Subdirectories may not be created within sbindir, for the same reason this is forbidden for bindir.

The default value of sbindir is $(exec_prefix)/sbin.

A profile may set sbindir equal to bindir. Therefore, software packages may not install files with the same base name in both directories.

Executable files that are primarily or exclusively meant to be run by other programs, rather than directly by humans, should be installed in this directory.

Executables that implement system services are an exception; despite usually being run by another program (the system service orchestrator), they should be installed in sbindir.

All the requirements on files installed in bindir also apply to files installed in libexecdir.

Unlike bindir, software packages may create subdirectories of libexecdir and place executables within these subdirectories.

The default value of libexecdir is $(exec_prefix)/libexec.

A profile may set libexecdir equal to libdir. Therefore, software packages may not install files with the same relative pathname in both directories.

System-wide configuration files—that is, editable files, meant to modified by the system administrator, to adjust the default behavior of one or more programs for an entire machine—should be installed in this directory. Programs that need to install more than one or two configuration files in sysconfdir should create an appropriately named subdirectory and place all their configuration files inside.

Files that can be modified by individual users on a multi-user system, to adjust program behavior just for the user who modified them, may not be installed in this directory; they belong in users’ home directories. See Section 8.5, “User home directories”.

Files that define the default behavior of a program, but are not intended to be modified, may not be installed in this directory; they belong in datadir.

Installation processes must take care, when installing or updating files within sysconfdir, not to overwrite any local modifications to existing files.

Executable files may only be installed in sysconfdir if they are also “system-wide configuration files” as defined at the beginning of this section. (The shell scripts used by System V init to control startup and shutdown are a good example of executables that are also system-wide configuration files.) Machine-code executables may not be used as configuration files, because they are not editable.

Mutable files may not be installed in this directory; they belong in localstatedir.

The default value of sysconfdir is $(prefix)/etc.

No files are required to exist within sysconfdir. There are many files that almost always will exist, but nonetheless they should not be assumed to exist.

When the C library provides an API for looking up data that is usually stored in a well-known file within sysconfdir, there is no requirement for the data to actually be sourced from that file. In many cases, the data won’t be exclusively sourced from that file even when it does exist. Programs should therefore prefer the library APIs whenever possible.

“Header files” (files to be used as the direct object of the #include preprocessing directive) for any programming language in the C family should be placed in this directory.

C header files installed in this directory must be usable with an ISO C-compliant compiler, and should also be usable with a C++ compiler.

Executable, mutable, and machine-specific files may not be installed in this directory.

The default value of includedir is $(prefix)/include.

Machine-code libraries, whether statically or dynamically linked, should be installed in this directory.

Other architecture-dependent static shareable data files may also be installed in this directory, when there is no more specific installation directory for them. Such files should be installed into a subdirectory that identifies their purpose and/or format, unless there is a compelling reason why they need to be directly in libdir.

Miscellaneous architecture-independent static data files should instead be installed in datadir. However, it can be difficult to tell whether a file is truly architecture-independent; when in doubt, assume it isn’t.

Executable files may only be installed in libdir if they are also machine-code libraries and they do not need to be accessible as shell commands. (For example, GNU libc’s libc.so.6 is a machine-code library. It can be used as an executable, but this is a secondary function that doesn’t require it to be visible in PATH.)

Mutable and machine-specific files may not be installed in this directory.

The default value of libdir is $(exec_prefix)/lib.

Architecture-independent static shareable data files should be installed in this directory, if there is no more specific installation directory for them. All such files should be installed into subdirectories that identify their purpose, format, and/or the application that created them.

Software packages may not install files directly in datadir. Packages that need to install only a few files in datadir may use $(datadir)/misc instead of creating a directory in datadir.

Files which are architecture-dependent, executable, mutable, or machine-specific may not be installed in this directory. It can be difficult to be certain that files are architecture-independent; if there is any doubt, they should be placed in (a subdirectory of) libdir instead.

The default value of datadir is $(datarootdir).

Packaged color management files that are potentially useful to more than one application should be installed in this directory.

All the requirements on files installed in datadir also apply to files installed in $(datarootdir)/color.

The top-level directory $(datarootdir)/color may not contain any files; all files should be in subdirectories which identify the files’ purpose and/or format. At present, we specify only one such subdirectory: $(datarootdir)/color/icc stores color profiles in the ICC (International Color Consortium) v4 format [icc-specs].

Comprehensive lists of words in natural languages, for use by spelling checkers, should be installed in this directory.

All the requirements on files installed in datadir also apply to files installed in $(datarootdir)/dict.

Each list should be named using the English name for its language, in all lowercase ASCII letters, e.g. french or hokkien. When there is more than one spelling standard for a language, the common English identifier for the spelling standard should be prefixed to the language name, e.g. american-english and british-english. When there are several word lists available for a single language and standard, suffixes may be used to distinguish them, e.g. american-english-web2 and american-english-cracklib-small.

For compatibility with historical practice, if English word lists are installed, $(datarootdir)/dict/words should be a symbolic link to the word list for the system’s users’ preferred spelling standard for English. Spelling checkers should avoid using this link; instead, they should allow each user to select the word list they prefer, from all available.

All word lists installed in this directory should be plain text files with one word on each line, in the preferred collation order for the language. Word lists should be encoded in UTF-8 unless it is absolutely necessary to do otherwise (e.g. a word list for a language whose script hasn’t been added to Unicode).

Packaged printer descriptions in PostScript Printer Description (PPD) format [ps-printer-desc], that are potentially useful to more than one application, should be installed in this directory or a subdirectory. The organization of files within $(datarootdir)/ppd is unspecified.

All the requirements on files installed in datadir also apply to files installed in $(datarootdir)/ppd.

Packaged files useful to more than one SGML processor, such as ordinary catalogs (not centralized catalogs, see $(sysconfdir)/sgml), DTDs, entity definitions, and style sheets, should be placed in this directory.

The top-level directory $(datarootdir)/sgml may not contain any files; all files should be in subdirectories which identify the DTD to which the files are relevant, or, if they are relevant to more than one DTD, otherwise unambiguously identify the group of files within.

All the requirements on files installed in datadir also apply to files installed in $(datarootdir)/sgml.

Packaged files useful to more than one XML processor, such as schema definitions and style sheets, should be placed in this directory. Centralized catalogs are not to be installed in this directory; they belong in $(sysconfdir)/xml.

The top-level directory $(datarootdir)/xml may not contain any files; all files should be in subdirectories which identify the XML namespace to which the files are relevant, or, if they are relevant to more than one namespace, otherwise unambiguously identify the group of files within.

All the requirements on files installed in datadir also apply to files installed in $(datarootdir)/xml.

Files which help adapt a program to a particular community of humans (a locale) should be installed in subdirectories of this directory. For example, “catalogs” of messages emitted by a program, in several human languages, belong here.

All the requirements on files installed in datadir also apply to files installed in localedir.

The default value of localedir is $(datarootdir)/locale.

Localization data is stored in a structured hierarchy of subdirectories of localedir: <locale>/<category>/<files>.

The <locale> component identifies the community of humans. This component must be a locale identification string. Locale identification strings have the form <language>[_<territory>][.<encoding>][@<modifier>].

The <language> field identifies the language or language family spoken in the community, using one of the two- or three-letter language codes defined by ISO 639, written with lowercase ASCII letters. Two-letter codes must be used for all languages that have one.

The <territory> field, when present, identifies the geographic territory of the community and/or the geographic variant of the language family, using one of the two-letter country codes defined by ISO 3166, written with uppercase ASCII letters. For example, this is useful to distinguish peninsular Portuguese (pt_PT) from Brazilian Portuguese (pt_BR).

The <encoding> field, when present, identifies the character encoding preferred in the community. It should be in all lowercase ASCII letters and digits with minimal punctuation, e.g. “utf8”, not “UTF-8.”

The <modifier> field, when present, further categorizes the locale. It can be used to distinguish language variants that are inadequately handled by the <territory> component, or to allow for conflicting cultural requirements, such as competing definitions of collating order. It should be in all lowercase ASCII letters and digits with minimal punctuation.

The <category> component indicates what aspect of the locale is governed by the files within. The categories and their functions are:

Documentation in the format expected by the man command should be installed in subdirectories of this directory.

The default value of mandir is $(datarootdir)/man.

All the requirements on files installed in datadir also apply to files installed in mandir.

Manual pages are stored in a structured hierarchy of subdirectories of mandir: [<locale>/]man<section>[/<arch>]. The <locale> and <arch> components of this hierarchy are optional, as described below.

Individual manual pages should be stored with file names that end with a numeric suffix, matching their section number; for example, the manual page for the ls command should be installed to man1/ls.1, possibly within a <locale> directory.

Manual pages may be installed compressed, in which case the numeric suffix should be followed by the usual suffix identifying the compression format, e.g. man1/ls.1.gz for gzip-format compression.

As a precaution against name collisions, some large sets of package-specific manual pages have an additional alphabetical suffix inserted right after the section number. For example, the C function strvis might be provided by both the system C library and the third-party libbsd library. The C library’s version of the manpage should be installed as man3/strvis.3 and libbsd’s as man3/strvis.3bsd.

The <section> component of the manual page directory hierarchy classifies each manual page into one of eight topic-based “sections:”

Optionally, preformatted manual pages may be installed in a parallel set of directories at the section level: cat<section> holds the preformatted versions of the pages in man<section>. Preformatted manual pages may not be installed without the corresponding source-format manual pages. Cached copies of locally-formatted manual pages are not to be written back to the directories for preformatted manual pages; they must be written to $(localstatedir)/cache/man instead.

The <locale> component of the manual page directory hierarchy supports simultaneous installation of manual pages written in multiple languages. If this component is present, it must be a locale identification string that uniquely identifies the language for the manpages within that directory.

Systems which offer manual pages in only one language may omit the <locale> component and store the <section> directories directly in mandir. Systems which offer manual pages in more than one language should place all their manual pages in <locale> subdirectories.

The <arch> component of the manual page directory hierarchy supports simultaneous installation of several architecture-specific variants of man pages, for device drivers and other software that is tightly coupled to the computer’s hardware. It should only be used when necessary.

Documentation in the format expected by the info command should be installed in this directory.

All the requirements on files installed in datadir also apply to files installed in infodir.

The default value of infodir is $(datarootdir)/info.

Documentation in any format besides those used by man and info, such as HTML, PDF, and plain text, should be installed in subdirectories of this directory.

All the requirements on files installed in datadir also apply to files installed in docdir.

No files may be installed directly into docdir, only into a subdirectory named after the software package whose documentation it is.

The default value of docdir is $(datarootdir)/doc.

All persistent mutable files that are part of an installable software package should be installed to one of the subdirectories of localstatedir, defined in subsections of this section. Files may not be installed directly in localstatedir.

New subdirectories of localstatedir may be added in future revisions of this specification. All such directories will have system-wide functions, as the existing subdirectories do. Software packages may not unilaterally add new directories to the top level of localstatedir.

Programs that use persistent mutable files need to take precautions against unexpected modifications by other processes on the same system; see Section 2.2.4, “Handling of mutable files” for further discussion.

The default value of localstatedir is $(prefix)/var.

Programs should store all their transient mutable files in this directory or in one of its subdirectories. Programs that need to create only one or two transient files may place them directly in runstatedir; programs that need several transient files should create a subdirectory and place all their files within.

Software packages should never install anything in this directory, because all files in this directory, and all subdirectories not listed below, are completely erased every time the system is booted. The variable exists to tell programs where to find this directory at runtime.

For the same reason, programs that use this directory must be prepared to recreate everything they put here, from scratch, every time they start up. However, they must not assume the files they mean to create don’t exist, either; garbage files might be left over from a previous run of the same program. See Section 2.2.4, “Handling of mutable files” for further discussion.

Because runstatedir’s contents are erased on every boot, it is an exception to the normal rule that empty directories need not exist. For security reasons, the top level of runstatedir is writable only by root. System services that run as unprivileged users may therefore need to arrange for files and directories that they need in runstatedir to be created in advance during service startup.

The default value of runstatedir is $(prefix)/run.

Daemon processes that create “process identifier” (PID) files should place them directly within runstatedir and should name them <program-name>.pid, where <program-name> is the name of the daemon’s primary executable (the one installed in sbindir). For example, the crond daemon’s PID file should be named /run/crond.pid. Each PID file should contain the daemon’s numeric PID as ASCII decimal digits, with no padding on the left, followed by a newline character. For example, if crond was running as process 25, /run/crond.pid should contain three characters: 25␊.

Programs that create local sockets in order to provide system-wide services should place them within runstatedir, but the exact pathname of each is unspecified.

The following special-purpose files may exist at the top level of runstatedir. If they exist, they shall have the indicated contents, and applications that generate relevant records should update them. However, applications must not create them if they don’t already exist.