Filesystem Hierarchy Standard(FHS)

原文转载至：en.wikipedia.org/wiki//etc/X11

感谢维基百科！！！

Filesystem Hierarchy Standard

From Wikipedia, the free encyclopedia

  (Redirected from /etc/X11)

Filesystem Hierarchy Standard

Developed by	Linux Foundation
Initial release	14 February 1994; 20 years ago
Latest release	2.3 / 29 January 2004; 10 years ago
Website	Official website Official website (Historical)

The Filesystem Hierarchy Standard (FHS) defines the directory structure and directory contents in Unix and Unix-like operating systems, maintained by the Linux Foundation. The current version is 2.3, announced on 29 January 2004.^[1]

Directory structure

In the FHS all files and directories appear under the root directory "/", even if they are stored on different physical or virtual devices. Note however that some of these directories may or may not be present on a Unix system depending on whether certain subsystems, such as the X Window System, are installed.

The majority of these directories exist in all UNIX operating systems and are generally used in much the same way; however, the descriptions here are those used specifically for the FHS, and are not considered authoritative for platforms other than Linux.

Directory	Description
/	Primary hierarchy root and root directory of the entire file system hierarchy.
/bin	Essential command binaries that need to be available in single user mode; for all users, e.g., cat, ls, cp.
/boot	Boot loader files, e.g., kernels, initrd.
/dev	Essential devices, e.g., /dev/null.
/etc	Host-specific system-wide configuration files There has been controversy over the meaning of the name itself. In early versions of the UNIX Implementation Document from Bell labs, /etc is referred to as the etcetera directory,[2] as this directory historically held everything that did not belong elsewhere (however, the FHS restricts /etc to static configuration files and may not contain binaries).[3] Since the publication of early documentation, the directory name has been re-designated in various ways. Recent interpretations include backronyms such as "Editable Text Configuration" or "Extended Tool Chest".[4]
/etc/opt	Configuration files for add-on packages that are stored in /opt/.
/etc/sgml	Configuration files, such as catalogs, for software that processes SGML.
/etc/X11	Configuration files for the X Window System, version 11.
/etc/xml	Configuration files, such as catalogs, for software that processes XML.
/home	Users' home directories, containing saved files, personal settings, etc.
/lib	Libraries essential for the binaries in /bin/ and /sbin/.
/lib<qual>	Alternate format essential libraries. Such directories are optional, but if they exist, they have some requirements.
/media	Mount points for removable media such as CD-ROMs (appeared in FHS-2.3).
/mnt	Temporarily mounted filesystems.
/opt	Optional application software packages.[5]
/proc	Virtual filesystem providing information about processes and kernel information as files. In Linux, corresponds to a procfs mount.
/root	Home directory for the root user.
/run	Information about the running system since last boot, e.g., currently logged-in users and running daemons.
/sbin	Essential system binaries, e.g., init, ip, mount.
/srv	Site-specific data which are served by the system.
/tmp	Temporary files (see also /var/tmp). Often not preserved between system reboots.
/usr	Secondary hierarchy for read-only user data; contains the majority of (multi-)user utilities and applications.[6]
/usr/bin	Non-essential command binaries (not needed in single user mode); for all users.
/usr/include	Standard include files.
/usr/lib	Libraries for the binaries in /usr/bin/ and /usr/sbin/.
/usr/lib<qual>	Alternate format libraries (optional).
/usr/local	Tertiary hierarchy for local data, specific to this host. Typically has further subdirectories, e.g., bin/, lib/, share/.[7]
/usr/sbin	Non-essential system binaries, e.g., daemons for various network-services.
/usr/share	Architecture-independent (shared) data.
/usr/src	Source code, e.g., the kernel source code with its header files.
/usr/X11R6	X Window System, Version 11, Release 6.
/var	Variable files—files whose content is expected to continually change during normal operation of the system—such as logs, spool files, and temporary e-mail files.
/var/cache	Application cache data. Such data are locally generated as a result of time-consuming I/O or calculation. The application must be able to regenerate or restore the data. The cached files can be deleted without loss of data.
/var/lib	State information. Persistent data modified by programs as they run, e.g., databases, packaging system metadata, etc.
/var/lock	Lock files. Files keeping track of resources currently in use.
/var/log	Log files. Various logs.
/var/mail	Users' mailboxes.
/var/opt	Variable data from add-on packages that are stored in /opt/.
/var/run	Information about the running system since last boot, e.g., currently logged-in users and running daemons.
/var/spool	Spool for tasks waiting to be processed, e.g., print queues and outgoing mail queue.
/var/spool/mail	Deprecated location for users' mailboxes.[8]
/var/tmp	Temporary files to be preserved between reboots.

FHS compliance

Most Linux distributions follow the Filesystem Hierarchy Standard and declare it their own policy to maintain FHS compliance.^{[9][10][11][12]}

Some distributions that generally follow the standard deviate from it in some areas. Common deviations include:

• Modern Linux distributions include a /sys directory as a virtual filesystem (sysfs, comparable to /proc, which is a procfs), which stores and allows modification of the devices connected to the system, whereas many traditional UNIX and Unix-like operating systems use /sys as a symbolic link to the kernel source tree.^{[citation needed]}
• Modern Linux distributions include a /run directory as a temporary filesystem (tmpfs) which stores volatile runtime data, and which is being considered for the next version of the FHS.^[13] According to the FHS version 2.3, this data should be stored in /var/run but this was a problem in some cases because this directory isn't always available at early boot. As a result, these programs have had to resort to such trickery as using /dev/.udev, /dev/.mdadm, /dev/.systemd or /dev/.mount directories, even though the device directory isn't intended for such data.^[14] Among other advantages, this makes the system easier to use normally with the root filesystem mounted read-only.
  • This is a detailed example from Debian:^[15]
    • /dev/.* → /run/*
    • /dev/shm → /run/shm
    • /dev/shm/* → /run/*
    • /etc/* (writeable files) → /run/*
    • /lib/init/rw → /run
    • /var/lock → /run/lock
    • /var/run → /run
    • /tmp → /run/tmp
• Many modern UNIX systems (like FreeBSD via its ports system) install third party packages into /usr/local while keeping locally developed code in /usr.
• Some Linux distributions no longer differentiate between /lib versus /usr/lib and have /lib symlinked to /usr/lib.
• Some Linux distributions no longer differentiate between /bin versus /usr/bin and /sbin versus /usr/sbin. They symlink /bin to /usr/bin and /sbin to /usr/sbin. And /usr/sbin may get symlinked to /usr/bin.