原文转载至:en.wikipedia.org/wiki//etc/X11
感谢维基百科!!!
Developed by | Linux Foundation |
---|---|
Initial release | 14 February 1994 |
Latest release | 2.3 / 29 January 2004 |
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]
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. |
|
Essential command binaries that need to be available in single user mode; for all users, e.g., cat, ls, cp. |
|
Boot loader files, e.g., kernels, initrd. |
|
Essential devices, e.g., /dev/null . |
|
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] |
|
Configuration files for add-on packages that are stored in /opt/ . |
|
Configuration files, such as catalogs, for software that processes SGML. |
|
Configuration files for the X Window System, version 11. |
|
Configuration files, such as catalogs, for software that processes XML. |
|
Users' home directories, containing saved files, personal settings, etc. |
|
Libraries essential for the binaries in /bin/ and /sbin/ . |
|
Alternate format essential libraries. Such directories are optional, but if they exist, they have some requirements. |
|
Mount points for removable media such as CD-ROMs (appeared in FHS-2.3). |
|
Temporarily mounted filesystems. |
|
Optional application software packages.[5] |
|
Virtual filesystem providing information about processes and kernel information as files. In Linux, corresponds to a procfs mount. |
|
Home directory for the root user. |
|
Information about the running system since last boot, e.g., currently logged-in users and running daemons. |
|
Essential system binaries, e.g., init, ip, mount. |
|
Site-specific data which are served by the system. |
|
Temporary files (see also /var/tmp ). Often not preserved between system reboots. |
|
Secondary hierarchy for read-only user data; contains the majority of (multi-)user utilities and applications.[6] |
|
Non-essential command binaries (not needed in single user mode); for all users. |
|
Standard include files. |
|
Libraries for the binaries in /usr/bin/ and /usr/sbin/ . |
|
Alternate format libraries (optional). |
|
Tertiary hierarchy for local data, specific to this host. Typically has further subdirectories, e.g., bin/ , lib/ , share/ .[7] |
|
Non-essential system binaries, e.g., daemons for various network-services. |
|
Architecture-independent (shared) data. |
|
Source code, e.g., the kernel source code with its header files. |
|
X Window System, Version 11, Release 6. |
|
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. |
|
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. |
|
State information. Persistent data modified by programs as they run, e.g., databases, packaging system metadata, etc. |
|
Lock files. Files keeping track of resources currently in use. |
|
Log files. Various logs. |
|
Users' mailboxes. |
|
Variable data from add-on packages that are stored in /opt/ . |
|
Information about the running system since last boot, e.g., currently logged-in users and running daemons. |
|
Spool for tasks waiting to be processed, e.g., print queues and outgoing mail queue. |
|
Deprecated location for users' mailboxes.[8] |
|
Temporary files to be preserved between reboots. |
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:
/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]/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.
/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
/usr/local
while keeping locally developed code in /usr
./lib
versus /usr/lib
and have /lib
symlinked to /usr/lib
./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
.