Talk:Filesystem Hierarchy Standard

From Wikipedia, the free encyclopedia

This is the talk page for discussing improvements to the Filesystem Hierarchy Standard article.
Please sign and date your posts by typing four tildes (~~~~). Put new text under old text. Click here to start a new topic. New to Wikipedia? Welcome! Ask questions, get answers. This is not a forum for general discussion about the article's subject.	Be polite Assume good faith No personal attacks Be welcoming	Article policies No original research Neutral point of view Verifiability

Contents 1 Information needed 2 Linux specific? 3 Rationale? 4 /opt 5 /usr 5.1 /usr as a backronym 6 Opt - english word also... 7 Mention other common directories? 8 /etc 9 /dev/bus 10 more OS X directory info 11 Disputed 12 Essential devices? 13 Relation to LSB? 14 Distributions supporting FHS

[edit] Information needed

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)

[edit] Linux specific?

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)

[edit] Rationale?

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)

[edit] /opt

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)

[edit] /usr

[edit] /usr as a backronym

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]

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)

[edit] Opt - english word also...

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's also option and maybe a book or two. I'll disambiguate with a pointer to Wiktionary. aele * 2006-05-16t20:05z

There already is a dab page for the word opt. --Unixguy 13:04, 17 May 2006 (UTC)

I just created it yesterday. aele * 2006-05-17t20:08z

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)

[edit] Mention other common directories?

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)

[edit] /etc

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)

[edit] /dev/bus

Daily WTF thread - I leave you to draw your own conclusions. Emurphy42 23:22, 27 November 2006 (UTC)

[edit] more OS X directory info

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)

[edit] Disputed

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)

[edit] Essential devices?

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)

[edit] Relation to LSB?

What is the relation to Linux Standard Base? --Apoc2400 10:36, 9 April 2007 (UTC)

[edit] Distributions supporting FHS

What Linux (and other) distributions support comply with FHS? --Apoc2400 10:36, 9 April 2007 (UTC)