
Understanding the linux filesystem (/etc, /var, /bin, /opt etc.) - alexholehouse
http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/
======
sciurus
I think the Filesystem Hierarchy Standard is a better resource than this.
Version 2.3 can be browsed at
[http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html](http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html).
Development of version 3.0 (the first update since 2004) began in 2011; you
can see a draft at
[http://www.linuxbase.org/betaspecs/fhs/fhs/index.html](http://www.linuxbase.org/betaspecs/fhs/fhs/index.html)

~~~
yajoe
I've used linux for years (15? 20? get off my lawn... :)

Thank you for posting this link! I never knew _why_ the paths were what they
were, I could only explain _what_ to expect in each.

------
chalst
I put up an explanation of the difference between /bin, /usr/bin,
/usr/local/bin, and ~/bin, as part of an argument why the "robustness" of
using #!/usr/bin/env $binname vs. hardcoding #!/path/to/binname is not a good
thing:

> The reason that depending on PATH is not considered good practice is that
> the script can make no assumptions about the content of the PATH environment
> variable, breaking the "sequential dependency model" of binaries where

1\. /bin contains the executables needed at boot time;

2\. /usr/bin contains the other executables used by the OS installation;

3\. /usr/local/bin contains executables installed by the system administrator
that are not part of the base OS.

4\. ~/bin contains the user's own executables.

> Each level should not assume the existence of binaries later in the
> sequence, which are more "application" but may rely on binaries earlier,
> which are more "fundament". And the PATH variable tends to run from
> applicationy to fundamental, which is the opposite direction to the natural
> dependency above.

> To illustrate the problem, ask yourself what happens if a script in ~/bin
> invokes an script in /usr/local/bin that invokes Ruby? Should that script
> depend on the OS installed version at /usr/bin/ruby, or on the personal copy
> the user happens to have at ~/bin/ruby? PATH searching gives the
> unpredictable semantics associated with the latter (maybe ~/bin/ruby is a
> broken symbolic link), while baking in the path to #! gives the former.

On the Unix&Linux SX -
[http://unix.stackexchange.com/a/11917/5197](http://unix.stackexchange.com/a/11917/5197)

~~~
graylights
I've historically been of opinion that #!/bin/name is preferred. Then I hit a
workplace with network mappings and mixed architecture servers. It makes me
appreciate linux's default mapping because when you start going off on your
own it becomes nasty.

Some machines only have python 2.4 and others 2.7. So /usr/local/python is not
a good answer for python scripts in /project/x/bin (network mapped). Worse
someone puts gnu coreutils in /project/x/bin, but for sparc architectures, so
PATH becomes touchy if you're on a x86 server.

I've resorted to having my bashrc build my path by scanning uname for
architecture/platform and conditionally adding path entries to these network
folders.

All organization scripts on network drives now have caveats "This only works
on linux x86 servers" or "This only works on server X". Not because it can't
work elsewhere, but because the PATH and #! management problems when the
dependencies are installed at different places on different servers.

Blegh </rant>

~~~
chalst
You could create a script /usr/bin/dispatch that contains

    
    
        #!/bin/sh
        file=`env PATH=$THIS_ARCHITECURES_PREFERRED_PATH /usr/bin/which $1`
        shift; exit "$file" "$@"
    

for each machine to use in your scripts. Tuning the path becomes a once per
architecture, rather than once per script, task.

------
hendry
I prefer the simpler filesystem proposal from
[http://sta.li/filesystem](http://sta.li/filesystem)

The FHS has been poorly done for years. For e.g. where is the canonical place
for a Web vhost root? /srv/www? /srv/web? /var/www?

~~~
gizmo686
That looks like a really cool idea.

One thing I don't like about its filesystem is its insistence that all
binaries go into /bin. As a user, I greatly appreciate the concept of having
some sort of /local directory to distinguish between files (or just executable
in this case) which the end user installed and which are part of the
distribution. If you abandon the idea that /bin has no subdirecories, then I
could see /bin/local as a viable alternative (although I think I would still
prefer a /local folder where that had /local/bin, /local/etc ...).

~~~
dredmorbius
The point of standards is that they define how _others_ (distros, vendors)
should interact with your system.

Debian Policy makes this more explicit by noting that it defines what packages
(and hence: package maintainers) _must_ do, _may_ do, and _must not_ do.

Among the latter: other than creating some of the hierarchy under /usr/local,
packages _may not_ delete content under this tree. That is for local system
management.

Similarly, /opt as a location where third-party vendors can install their
crap, excuse me, packages, is a pretty well established standard. Note too
that you can offer the _filesystem_ view _independent of_ the underlying
_storage_ view, whether by symlinks (e.g., ln -s /usr/local/opt /opt), union
mounts, or other means.

Any parts of the filesystem you create _outside_ the defined standards are
pretty much yours to worry about, though I've also got extreme reservations
about polluting the root filesystem excessively. Better to create a structure
under /usr/local or elsewhere (if for no other reason: it simplifies backups).
This is a practice often respected in the breach in reality, however....

------
IvyMike
Not enough people know this, but when you say "etc" out loud in reference to
the directory, it is supposed to sound like "etsy".

I expect there will be people who reply to this comment to argue it should be
"E-T-C" or "Et Cetera". You can ignore those people; they probably say
"exclamation mark" instead of "bang".

~~~
numeromancer
You should go, say, six months, in which you never use “suppose” in the
passive voice. Whenever you feel the inclination to say “it is supposed...” or
“you're supposed to...”, force yourself to rephrase your sentence in the
active voice. This requires, of course, that you find a supposer, and name
him. At that point you will discover what it is you're really trying to say.

~~~
IvyMike
> Not enough people know this, but when you say "etc" out loud in reference to
> the directory, you should say "etsy".

Not really a big difference in meaning or tone, if you ask me.

~~~
numeromancer
You didn't use “suppose”.

~~~
IvyMike
Can't you just tell me what you suppose [1] I was "really trying to say"? As
it is, your point is over my head.

[1] Ha!

~~~
numeromancer
Sure:

> Not enough people know this, but when you say "etc" out loud in reference to
> the directory, I suppose it should sound like "etsy".

The passive voice, combined with the opening phrase, gives the false
appearance that the subject is the pronunciation of ‘/etc’, when the true
subject is you. I put it the way I did because it is a good exercise and
because I didn't want it to seem impetuous.

~~~
IvyMike
That changes the meaning quite a bit--in the original, the word "suppose" was
used in the sense of an obligation; in the new sentence, the word "suppose" is
used to mean "a guess".

If you're saying that I was being passive aggressive, that's my bad, because I
was aiming for over-the-top bravado and didn't go big enough for it to be
funny, I guess.
[http://dilbert.com/strips/comic/1995-06-24/](http://dilbert.com/strips/comic/1995-06-24/)

------
talloaktrees
I wrote a utility called 'dirhelp' that can give you info on any directory:
[https://github.com/jrenner/linux-directory-
help](https://github.com/jrenner/linux-directory-help) It's written in Go,
binaries are available in the repo

~~~
yankcrime
hier(7) accomplishes largely the same thing.

------
contingencies
_/ srv_ baby! Since I discovered that had semi-official support (even though
it often doesn't exist), I've rarely written elsewhere. Makes far more sense
than _/ var/www/_ and _/ var/lib/..._ paths for different daemons to me.

------
TerraHertz
Some related articles:

20120128
[http://lists.busybox.net/pipermail/busybox/2010-December/074...](http://lists.busybox.net/pipermail/busybox/2010-December/074114.html)
Understanding the bin, sbin, usr/bin, usr/sbin split

Ohhh THATS why! Taking the meaning of 'legacy' to new extremes. This very
detail, is one of the prime reasons I refuse to use Linux. I have always
thought the categorization of folder usage was insane. Now I know WHY it's
insane.

20030430 [http://www.osnews.com/story/3431](http://www.osnews.com/story/3431)
[http://www.osnews.com/story/3431/If_I_Had_My_Own_Distro/page...](http://www.osnews.com/story/3431/If_I_Had_My_Own_Distro/page2/)
[http://www.osnews.com/story/3431/If_I_Had_My_Own_Distro/page...](http://www.osnews.com/story/3431/If_I_Had_My_Own_Distro/page3/)
If I Had My Own Distro (Linux)

------
quackerhacker
_/ usr/games_

One of my pet peeves when I work on clusters before I even mess with the fstab
or ufw is always deleting this folder.

~~~
kryten
Why bother. Just leave it there.

~~~
quackerhacker
It's just a pet peeve.

Since alot of the clusters I work on are web servers or parallel computing
servers (that still have access through to a network), I like to clear out any
dirs and files that aren't needed, mount ro access to any dirs that shouldn't
be written to, and do every other thing I do to lock down the server.

It's helped me before detect unauthorized files that contained malicious code.

------
bbanyc
Fedora has made some major changes to the hierarchy recently (merging /bin and
/lib into /usr, introducing /run) that will be present in RHEL 7.

/run has been widely adopted, but the /usr merge is a bit more controversial.
I expect this will become another factor in the growing bifurcation of Linux
into Red Hat-style distros and Ubuntu-style distros (see also systemd vs.
upstart, Wayland vs. Mir, etc.) with a few "traditionalist" distributions like
Slackware on the sidelines. As a Debian user, I expect that the next few years
will be...interesting.

------
chacham15
I remember reading an article that discussed why there were so many folders
that seemed to have the same purpose (e.g. /bin,/sbin,/usr/bin) and the reason
was that hard drives were so small that they needed to make sure that the
essentials were available on boot. Seeing as how this isnt an issue anymore,
why do we persist this same structure? E.g. to me the Mac filesystem seems to
make much more sense and for the large part has eliminated all of this
redundancy. Why isnt Linux in general following suit?

~~~
ordinary
[http://lists.busybox.net/pipermail/busybox/2010-December/074...](http://lists.busybox.net/pipermail/busybox/2010-December/074114.html)

------
nathell
While ubiquitous, this is not strictly necessary for a Linux system. For an
example of a distro that makes a radical departure from FHS, see GoboLinux
(sadly seems to be not updated anymore).

------
Aissen
Unfortunately this is obsolete in many modern distros, including Fedora and
Archlinux, because of the /usr merge:
[http://fedoraproject.org/wiki/Features/UsrMove](http://fedoraproject.org/wiki/Features/UsrMove)

Also it doesn't take /run into account (for which many distros had a hack
before settling on /run).

------
FreakyT
I never understood why this hasn't been modernized. The three-letter nearly-
meaningless directory names seem so obsolete.

~~~
quackerhacker
Unless your ssh'd into a machine, it's annoying to type long dir's. What's
worse is compensating for spaces in filenames.

~~~
freework
Thats what tab completion is for.

~~~
quackerhacker
Thank you freework, didn't know about that one (embarrassing as it is to
admit).

Still sucks dealing with spaces when it comes to command processes like ffmpeg
-i <no_tab>...but awesome for cd'ing or ls'ing!

~~~
kanemathers
Just prefix the space with a backslash. Eg: ``$ ls /foo/bar/my\ directory/``.
With that backslash in place, you can continue your tab-completion.

~~~
iSnow
Still, on some international keyboards, backspace is hard to reach, eg. on a
German Mac keyboard, is it <alt><shift>7.

So don't put spaces in path names, it's a bitch to work with.

~~~
emillon
You can quote the space:

    
    
        mkdir x\ y
        cd x' 'y
    

(or the entire part: cd 'x y')

~~~
quackerhacker
Yup, that's what I do too, or %20 if its a url

------
cabalamat
What do people think if the way Gobolinux does it? It seems a more sensible
(and understandable filesystem hierarchy to me, but I wonder if there are
problems with the idea).

Gobolinux: [http://www.gobolinux.org/](http://www.gobolinux.org/)

~~~
kmicklas
Nix/NixOS ([http://nixos.org/](http://nixos.org/)) is a more modern package
manager/distro with many goals similar to GoboLinux, but that is actively
maintained and has a number of other benefits.

------
dmourati
Amazing how few people I've worked with have any concept of FHS.

------
merlincorey
In FreeBSD, we have `man hier`

    
    
        HIER(7)            FreeBSD Miscellaneous Information Manual            HIER(7)
        
        NAME
             hier — layout of file systems

