Talk:Filesystem Hierarchy Standard/Archive 1
Information needed
[edit]I added some indication of where the directory names are derived from (using bolding). However I don't know about a few key directories, e.g. etc, proc and opt. Could someone please add these? --HappyDog 11:43, 8 Nov 2004 (UTC)
Linux specific?
[edit]Can anyone name a single non-Linux/non-GNU operating system which implements this? I know that none of the BSDs do, nor are they ever likely to. 18.26.0.18 03:54, 26 Feb 2005 (UTC)
- So, what's the structure of a BSD filesystem? I know that Solaris has most of the main ones down, like /bin /etc /home /mnt /usr /tmp etc?
- See, for example, FreeBSD 5.3's hier(7) manual page (but be aware that the mdoc-to-html renderer does a bad job with the tables in this page). You should also note that FHS copied popular Linux distributions which copied Solaris (which copied SVR4), so Solaris is not a particularly good example to point to. 18.26.0.18 05:39, 22 Mar 2005 (UTC)
Rationale?
[edit]Does anyone know if there's rationale to this layout? For example, why scatter the components of a single package all over the filesystem? Why not have each package correspond to a single directory (or even a finite number of directories) where all of their contents are stored? 192.160.6.252 22:17, 11 Mar 2005 (UTC)
- I suspect that since a user is discouraged from removing packages by direct file deletion, but by use of uninstallation scripts, actual folder location is not very important. The standardised layout helps greatly in working out interdependencies, and also is helpful in PATH parameters for what is a primarily commandline-driving OS. I suppose. (In the non-FHS Windows OS, this is duplicated, for example, by depositing dll files in the windows/system directory, commonly executed programs in the windows/command directory, configuration files in the windows directory, or within the system registry database, usual program files in the program files directory... and so on.) Aesthetically, it looks much neater than clogging up root, which is the case on my windows partition.--Fangz 14:07, 20 Mar 2005 (UTC)
- Well, many programs share files, so it's nice to have a standard place for a program to find them. Then there is GoboLinux which breaks the FHS in order to make more sense.--Swift 11:53, 12 October 2005 (UTC)
- There are 2 ways to organize files. Call them 'function' (executable vs configuration vs data..) and 'context' (everything having to do with apache). A working admin far prefers 'function', that is, all the logs in one place (/var/log/), all config files in one place (/etc/), so that I can quickly ls and grep them and so on when troubleshooting. Or again, a limited number of directories for executables that can be in a $PATH. Shared resources (eg libraries) as mentioned is another big deal. —Preceding unsigned comment added by 24.27.63.161 (talk) 20:41, 5 August 2009 (UTC)
- This is an excellent question, for people need to know how best to partition their disks. This varies with the individual. The answer has changed greatly since the 1980s. At that time speed did matter, and backup media were limited in capacities. One needs to examine the history of computing devices to fully understand the rationale of this organization; and examine the history of the Unix file system (which evolved to reduce thrashing, for example). Someone who has been a system programmer since the 70s could probably answer this; and the answer would likely fill an article. It would be well worth this, especially if partitioning advice for various kind of storage devices were included. Geologist (talk) 01:27, 4 September 2009 (UTC)
/opt
[edit]I'm not sure the definition we have listed here is clear. I'm still no wiser on what /opt is for without actually clicking through to the specification. Chris 19:54, 20 Mar 2005 (UTC)
- I asked the same question on Wikipedia:Reference desk but didn't get a concrete answer either. Here is the post. Jay 09:52, 1 February 2006 (UTC)
- In UNIX operating systems, there is a standard directory by name /opt. Is it an acronym ? What does it stand for ? Filesystem Hierarchy Standard has got meanings of all standard directories except /opt. Jay 18:17, 14 January 2006 (UTC)
- See [1]. Its name stands for optional. – b_jonas 18:34, 14 January 2006 (UTC)
- Thanks for the link. But I couldn't find where it says that opt stands for optional. Can you point out the line ? Jay 09:18, 15 January 2006 (UTC)
- I think I was just guessing with optional. I don't think the standard says it anywhere. Sorry. – b_jonas 14:43, 15 January 2006 (UTC)
/usr
[edit]/usr as a backronym
[edit]- I have just removed any mentioning of /usr being a backronym from the article. That unbacked "fact" has been in Wikipedia for far too long. Please continue the discussion and provide proof for the backronym's existance in FHS terminology before reverting. Thanks, --Swift 05:47, 16 January 2006 (UTC)
Can somebody provide me with a link as to prove that 'usr' was an acronym for Unix Source Repository. I think that it is just a shortening of 'user' much like ls is short for list. -The preceding unsigned comment was added by 202.53.36.90 (talk o contribs) 04:51, 5 December 2005.
- Officially, I think it stands for Unix System Resources. It did, of course, derive from "user" originally. aele * 10:57, 5 December 2005 (UTC)
- Personally, after looking over the FHS, I find this highly unlikely. The FHS says that "/usr is shareable, read-only data". To me, that implies that although /usr can contain system resources, it is by no means the only directory for system resources (of which some reside in /etc). Therefore, it implies that /usr is nothing more than what everyone thinks it is; a shortening of user (like /src is a shortening of source).--Swift 20:34, 11 December 2005 (UTC)
- Yes, but Unix System Resources is a backronym. aele * 21:32, 12 December 2005 (UTC)
- Just that someone came up with an acronym to fit the characters, doesn't make it a backronym. /usr isn't specifically a UNIX system repository, shouldn't be called that and we have nothing concrete showing that anyone seriously calls it that (even aele -- the only one to suggest this -- isn't sure about this).--Swift 05:35, 16 January 2006 (UTC)
- But it *is* used a lot: [2]
- Just that someone came up with an acronym to fit the characters, doesn't make it a backronym. /usr isn't specifically a UNIX system repository, shouldn't be called that and we have nothing concrete showing that anyone seriously calls it that (even aele -- the only one to suggest this -- isn't sure about this).--Swift 05:35, 16 January 2006 (UTC)
- Yes, but Unix System Resources is a backronym. aele * 21:32, 12 December 2005 (UTC)
- According to various statements in the AT&T (Bell Labs) Unix manuals (7th Edition), /usr refers to "user". None of the 5th Edition Unix manuals mention "Unix System Resources" or "Unix Source Repository" at all. Quotes from "The_Unix_Programming_Environment" (Brian_Kernighan and Rob_Pike, Prentice-Hall, 1984) include
- "... /usr is a directory that contains the directories of all the normal users of the system."
- and
- "/usr is often the top directory of the user file system. (user is abbreviated to usr in the same spirit as cmp, ls, etc.) /usr/you is your login directory, your current directory when you first log in. /usr/src contains source for your system programs, /usr/src/cmd contains source for UNIX commands, /usr/src/cmd/sh contains the source files for the shell, and so on."
- and
Table 2.1: Interesting Directories (see also heir(7)) / root of the file system /bin essential programs in executable form ("binaries") /dev device files /etc system miscellany /etc/motd login message of the day /etc/passwd password file /lib essential libraries, etc. /tmp temporary files; cleaned up when system is restarted /unix executable form of the operating system /usr user file system /usr/adm system administration ...
-The preceding unsigned comment was added by 67.70.80.8 (talk o contribs) 30th of December 2005.
My resource for that meaning of /usr (Unix Special Resources) is the Computer Science department at the University of Erlangen, Germany, who is known in these parts for their contributions to unix and unix like systems. I suppose the manuals sited below are better, but I still think it is an open question. -- an.echte.trilingue
This is the link: http://wwwcip.informatik.uni-erlangen.de/old/tree/CIP/Manuals/unix/namen.html
- As far as i know, in the beginning of UNIX there were relatively few programs installed compared with today, and it made no sense to try and divide between user binaries and system binaries. /usr (yes, user) was originally only for what we call "home directories" today. Gradually as UNIX and computer use in general grew, the focus for /usr began to shift from "user files" to "anything user-related". Obviously, this merging eventually turned out into a mess, and therefore /home was created to house user files. Somewhere later in history the kind of backronyms were invented for this new use of /usr. It was a logical consequence of the growth of the system -- De Zeurkous (root@lichee.nichten.info), Thu Jun 8 00:36:42 UTC 2006
- Recently I contacted the freestandards-fhs-discuss mailing list, asking for any pointers to the etymology of
/usr
. I got a reply from one Alfred M. Szmidt, who claimed the following:- /usr - users: user directories where stored here, and /usr was usually mounted on a bigger disk than the actual root file-system so things got installed in there (it was also mounted quite later, so you didn't have any programs or data that one needed during system start up). A couple of the BSD's only "recently" (a few years back) changed from using /usr for user directories to /home.
- He furthermore suggested that I go seek old
hier(7)
man pages and after searching through the FreeBSD Hypertext Man Pages, I could find no mention of what/usr
stood for. Most of the man pages, however, mentioned that the data in the directory was "user"-something (e.g. "user utilities and applications"). - Finally, I checked this old UNIX System V Release 4: An Introduction that I have. Looking through it, there are also no mentions of what /usr stands for, but:
- "/usr This contains other user accessible directories such as ..." (p. 81)
- "The /usr file system contains commands and system administrative databases that can be shared."
- I have very little doubt any more that
/usr
stands for "user". --Swift 01:02, 8 June 2006 (UTC)- Hehehe, that's why i came to this article :) As a result of this whole debate, we could even make a "real" /usr article with the information gathered here -- De Zeurkous (root@lichee.nichten.info), Thu Jun 8 01:06:32 UTC 2006
Geez, am I really that old? Of course /usr is just a shortening of "user", regardless how many recent sources may have made up other silly folk etymologies for it--and any source later than the 1970s is recent as far as Unix is concerned. Just ask Dennis, for God's sake, he's still around. Likewise, /etc was just short for "et cetera". No one who developed on or for Unix in the 70s and early 80s (myself included) had the slightest doubt about either of these. --LDC 17:34, 3 March 2007 (UTC)
Opt - english word also...
[edit]The word "opt" is also a word in the english language. So I think this should become a disambiguation page, though I personally don't know how to create a page like that yet.
According to dictionary.com the word 'opt' also means: Select as an alternative; choose instead; prefer as an alternative; "I always choose the fish over the meat courses in this restaurant"; "She opted for the job on the East coast" Mzanime 16:55, 22 February 2006 (UTC)
- I disagree. Wikipedia is an encyclopedia, not a dictionary. I'm pretty sure there is an official policy on this somewhere.--Swift 00:04, 16 May 2006 (UTC)
- There already is a dab page for the word opt. --Unixguy 13:04, 17 May 2006 (UTC)
- Doh! So I see now. It looks good. Thanks! --Unixguy 13:25, 22 May 2006 (UTC)
What does opt mean in /opt? optional? 16@r 22:44, 22 October 2006 (UTC)
Mention other common directories?
[edit]Should this page mention some "standard" non-FHS (and not necessarily a published standard) locations that certain commonly-encountered systems use? Things like the */lib */lib32 */lib64 conventions and SGI's /usr/freeware come to mind. I'm afraid a separate page would just become a dumping-ground and would repeat much of the info from the page here. DMacks 17:53, 15 May 2006 (UTC)
/etc
[edit]Like /usr
and /sbin
, /etc
seems to have a range of assumed acronym etymologies. None of them seem to have any good solid sources to back them up so I removed them all. They candidates are/were:
- et cetera
- everything that configures
- essential text configuration
- extended tool chest
So far, I think "et cetera" is the best candidate. The other two are either too broad (not all configuration files lie in /etc
) or too narrow (not everything in /etc
is essential) to properly fit the purpose of /etc
. Still, I have seen no mention of this in an official document so I took it out as well. --Swift 23:16, 22 May 2006 (UTC)
- Originally (AFAIK) much of what is now located in various sbin-directories were in /etc (e.g. scripts to add new users and mount file-systems).
- While clearly not all configuration-files are located in /etc, many of the remaining ones are located in other etc-directories. The exception is clearly packages like KDE and GNOME; but these are first of all new (long after the etc-name came into use), and there is less need to make a system-wide default configuation for them (like there is for older programs like tin and pine). When the etc-directory came into use, most programs needed one or a few configuration-file, so it made sense to put them one place... these days, it makes more sense to keep the configuration-files with the package... my point is, when the name for the directory was coined, it pretty much did contain "everything that configures" (I'll try to dig-up where I saw the term first).
- To me, "etcetera" seems to broad... I go for "everything that configures"; though admittedly for a while it also contained scripts used by root... and though these days much configuration is moved elsewhere (but we're after the original meaning anyway). --Koppe
- Recently I contacted the freestandards-fhs-discuss mailing list, asking for any pointers to the etymology of some of the directory names that have been debated on this talk page. I got a reply from one Alfred M. Szmidt, who claimed the following about
/etc
:- /etc - etcetera: anything that didn't belong somewhere elsewhere. Used to contain maintenance programs and data files and other important stuff like rmt, mount, cron, init, getty, and other cruft like that. It also contained a shell and a voice synthesizer I think...
- He furthermore suggested that I go seek old
hier(7)
man pages and after searching through the FreeBSD Hypertext Man Pages, I could find no mention of what/etc
stood for. Most of them said something along the lines of: "system configuration files and scripts". - Finally, I checked this old UNIX System V Release 4: An Introduction that I have. Looking through it, I can find no mentions of what /etc stands for, but:
- "/etc This contains system administration and configuration databases." (p. 8)
- "/etc This directory is where many basic administrative commands and directories are kept." (p. 779)
- There is still very little evidence pointing either way. Since "et cetera" is the most commonly associated meaning with the characters "etc" and I have seen no reference to anyone mentioning something like "oh, and by the way; /etc isn't et-cetera", I would conclude that, in all likelyhood,
/etc
stands for the common abbreviation for "et cetera" --Swift 01:20, 8 June 2006 (UTC)
- I've heard it as 'Editable Text Configuration' - It's the main place where all configuration files go, and these are generally human-readable and -editable. (As opposed to binary non-human-editable files as popular for a long time in DOS and still nowadays in that stupid windows Registry) DrYak 21:04, 3 March 2007 (UTC)
Of course it's for "et cetera"--see my not above under /usr. --LDC 17:34, 3 March 2007 (UTC)
If there were still any doubts, Peter Salus received email from Dennis Ritchie:
I assure you that the original contents of /etc were the "et cetera" that didn't seem to fit elsewhere. Other variants might do their own etymologies differently. Regards, Dennis
Uh-oh, this has been Slashdotted: http://ask.slashdot.org/article.pl?sid=07/03/03/028258 Xiamcitizen 18:28, 3 March 2007 (UTC)
/dev/bus
[edit]Daily WTF thread - I leave you to draw your own conclusions. Emurphy42 23:22, 27 November 2006 (UTC)
more OS X directory info
[edit]I have thought of adding this after the Mac OS X lines:
However, the FHS is invisible to most Mac OS X applications, and can be viewed via the terminal or any Unix programs (I.E. programs that don't use the Carbon and Cocoa frameworks).
Is this okay? -Madd the sane 07:09, 22 December 2006 (UTC)
Disputed
[edit]Who said /var/tmp/ is preferred in multi-user mode? AFAIK, all the FHS says is that the files in /var/tmp should be preserved between reboots. Jorge Peixoto 17:15, 5 January 2007 (UTC)
- Both the OpenAddict edition and the pathname.com editition of FHS say preserve between reboots and longer auto-delete aging, and say nothing about multiuser mode. DMacks 17:26, 5 January 2007 (UTC)
- I think it's more under the assumtion that multi-user-mode usually *also* means fully-mounted -- in other words, after the partition containing /var (or /var/tmp) has been mounted. After that, /var/tmp *should* be used, because it's usally larger than /tmp and because you don't want to much writing in / (the root-partition) (as that would increase the chance of corruption there). /tmp should only be used when it has to; by programs started at boot, by the programms/commands used in single-user-mode (those in /bin and /sbin) and by daemons started at boot (but before mounting filesystems) (e.g. giving the daemons a place to dump core if nothing else). So it's perhaps not a *standard*, but it's certainly "good practice" -- and makes sence. koppe 14:30, 2 February 2007 (CET)
Essential devices?
[edit]I see /dev is explained as "Essential devices", but shouldn't it be *just* "devices" ? First of all, many of the devices aren't *that* "essential", but more importantly, are there any other places device-special-files will normally go? I thought pretty much all of them will in this directory - essential or not. BTW, it would perhaps be a good idea to mention that /dev these days often functions as just a mount-point for the kernel(?)-generated dev-filesystem, and *not* a place where device-special files actually exists (as in the "good ol' days"). [User:koppe|koppe] Monday 26. February 2007, 00:30 (CET)
Relation to LSB?
[edit]What is the relation to Linux Standard Base? --Apoc2400 10:36, 9 April 2007 (UTC)
- Yes, I should like to know this. LSB appears to have a recommended hierarchal file system (and rules for application programmers), which I couldn't easily find. How these relate to partitions I should think would be a more personal decision. Geologist (talk) 02:34, 4 September 2009 (UTC)
Distributions supporting FHS
[edit]What Linux (and other) distributions support comply with FHS? --Apoc2400 10:36, 9 April 2007 (UTC)
Filesystem belongs to Linux operating system
[edit]Editors of this article should be reminded that filesystem belongs to Linux Operating System and not for GNU/Linux development platform or any of software systems (Linux distributions). http://www.amazon.com/gp/reader/0130313580/ref=sib_dp_pt/103-7158569-1619062#reader-link http://www.usenix.org/publications/login/2006-04/openpdfs/herder.pdf http://www.computer.org/portal/site/computer/menuitem.5d61c1d591162e4b0ef1bd108bcd45f3/index.jsp?&pName=computer_level1_article&TheCat=1005&path=computer/homepage/0506&file=cover1.xml&xsl=article.xsl& http://www.topology.org/human/?a=/linux/lingl.html We have different standards for Linux OS file systems and this should be standardised on LSB. The LSB is designed for Linux OS so all software systems what use the Linux OS or GNU/Linux software platform. —Preceding unsigned comment added by 213.130.236.207 (talk) 08:21, 18 October 2008 (UTC)
home bin directory
[edit]There's a /home/username/bin directory in the $PATH. It would seem this is for software run as a user. How is this meant to be used? —Preceding unsigned comment added by 71.167.64.95 (talk) 19:45, 25 May 2009 (UTC)
This article needs to be better known
[edit]This is a wonderful article, containing material I always look for with 'hier' when asked to use a new Unix or Linux operating system. Of greatest value is the authors' guessing the meaning of *nix directory names in the description. Command-line executables need similar descriptions (for who could guess what 'biff' means?). (Such descriptions, to my knowledge, were never provided by the original Unix developers.)
This would likely be one of the most sought-after articles on computing, if people knew it existed. How is one to find it? When I typed in 'hier', I was told of an appliance company in China. 'Unix file system' took me to a page with no hint of this one's existance. This I'm making an icon in a programming folder.
Can someone make it more easily found? Perhaps the Wikipedia has a list of alias phrases?
Geologist (talk) 01:07, 4 September 2009 (UTC)
- The Wikipedia term for helping readers find alternate meanings of a term is "disambiguation". I added the following note at the beginning of the page you get when you look for the "hier" article:
- and added:
- to the top of the Unix File System page. Hope that helps! DMacks (talk) 02:33, 4 September 2009 (UTC)
- That helps greatly, thank you! 67.91.218.205 (talk) 21:09, 3 October 2009 (UTC)
Meanings & original uses of directories & file names
[edit]- Regarding the meanings behind interesting/nonobvious names, Wikipedia is not allowed to speculate about anything: we rely solely on published reliable sources for information. Biff is no mystery: the manpage on my OS X box provides an answer that agrees with the information given in the Biff article. Note that the article cites other sources so you can verify the information there. DMacks (talk) 02:38, 4 September 2009 (UTC)
- It's too bad that knowledgeable experts can't speculate. Was your man page written by the original author of 'biff'? To my knowledge, the author of 'biff' (a Berkeley command that ran an asynchronous mail notification daemon) never documented the meaning of that name. It was only rumored that 'biff' was the name of the dog that lingered around his hall at Berkeley (and barked at the postman). Reference 2 in the 'biff' entry, is Eric Cooper speculating that Biff barked at the postman, which makes sense; but reference 3, an oral statement by the original author, states Biff did not bark at the postman, which makes no sense. Time to clarify these things are running out. Curious minds want to know. :-) 67.91.218.205 (talk) 21:09, 3 October 2009 (UTC)
- Typing 'man lp' on my Debian Linux system produces 'lp - print files'. What does the 'l' stand for? Line printers are not common these days. A 'p' in a command almost always represents 'print'. Thus, 'pwd' is not 'present working directory', but 'print working directory'. How many people know that 'grep' meant 'global regular expression print', or 'ps' 'process status', not 'processes'? 67.91.218.205 (talk) 21:09, 3 October 2009 (UTC)
- In the 1970 & 80 I worked at a National Computing Center near Princeton, NJ, and visited Bells Labs in Cherry Hill frequently. It was clear at that time that people were all speculating on the the meanings of names of directories and traditional files. Though speculating that 'man' meant 'manual' or 'manual page' was clear, it was a speculation. The only reliable source, as you say, would be the manual page for the command written by the original author. 67.91.218.205 (talk) 21:09, 3 October 2009 (UTC)
- BTW, I had thought it brilliant that abbreviations were substituted for long commands. I had thought this was in anticipation of scripts & 'little languages', which was yet another brilliant innovation. Later I discovered it was only because neither Kernighan or Ritchie were touch typists. :-) If this weren't enough, tcsh (Tenex C shell) completes the tiny command after enough is typed to disambiguate the command, like Tenex! Some information is available only in 'oral history', and those who know are dying. It would be nice if the Wikipedia had a policy that allowed the collecting of this. Who, in the distant future, will know what 'lp' meant? 67.91.218.205 (talk) 21:09, 3 October 2009 (UTC)
practical reality of /usr/bin vs. /usr/sbin
[edit]I'm sure that this varies somewhat (or even greatly) depending on the distribution, but on at least some distributions these two directories are, for all practical purposes, redundant. I've read the FHS on the subject, but I've also found many forum articles that reference the common practice of either copying application binaries to both /usr/bin and /usr/sbin, or even symlinking one to the other so that they both point to the same directory.
Then I looked at my own ubuntu /usr, and found that /usr/bin and /usr/sbin contain identical binaries for most applications. In comparison, /bin and /sbin are substantially used for the purposes described by the standard FHS.
My point is that it's currently hard for new users, or intermediate users who are installing something manually for the first time, to figure out where to put binary files. I would have simply added a note to this article, but after searching a while I ended up stumped as to where to find a credible reference. Can one reference a distribution's file hierarchy?
Is there a reasonable way to include more "reality-based" information along with the official standard? And how much does this practice vary between distributions? Thank you kindly. Ivolucien (talk) 17:49, 6 October 2009 (UTC)
- Err, are you sure you saw that right? My /usr/bin of 1481 items and /usr/sbin of 236 items on a Debian system are almost completely different. The only matching items on this machine are cupsenable, cupsdisable, install-menu, lsusb, su-to-root and traceroute. --Joy [shallot] (talk) 22:04, 6 October 2009 (UTC)
Change of definition of /usr/lib
[edit]I was using this page as reference, and noticed that /usr/lib was listed as being libraries for binaries in /usr/bin and /usr/sbin. While it's true that /usr/lib is used for libraries for those binaries, there also exist libraries without executables (ie, standalone libraries to be tied into other things) just as there exist executables without libraries. I propose that we alter this definition to also include standalone libraries. --Gm4n (talk) 23:17, 22 January 2010 (UTC)
- Wikipedia does not define anything. Each distribution happens to implement the FHS in different ways, but that does not change the official definition of the standard — which is the subject of this article. --Swift (talk) 23:38, 22 January 2010 (UTC)