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.
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.
Thanks! I've always thought /usr/bin was for software later installed (due to its name "user slash binaries") and thought /usr/local/bin was useless. This actually makes more sense, gonna start installing programs to /usr/local/bin now.
Here is what the Unix manual from Bell Labs (the origin of Unix) says about /usr/bin versus /bin:
Commands generally reside in directory /bin
(for binary programs). Some programs also
reside in /usr/bin, to save space in /bin.
There were hardware limitations in the early days of Unix. Short command names (like “ls” and “rm”) were used to save memory and paper (teletypes were used in the days before video terminals). Each byte mattered back then. There must have been a constraint on how much they could put in /bin (I am guessing).
Or you run Arch, where every bin (including the sbins) is a symlink to /usr/bin, because in practice you just want your binaries in one place. Non-packaged binaries go in /usr/local/bin or something in opt.
>#!/usr/bin/env $binname vs. hardcoding #!/path/to/binname
All of these "solutions" fail somewhere because some system does it differently. Why can't one just use #!bash or #!python and have the system just look on the path for it?
Arch Linux recently merged /bin, /sbin, and /usr/sbin to /usr/bin [1]. The filesystem hierarchy is quite flat and well defined [2], kind of like your example.
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 ...).
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....
I really dislike the idea of /usr/local. Users should install everything through the package manager, otherwise stuff just collects in /usr/local and there's no easy way to remove it (if 3 different users install 5 different programs in /usr/local, how do you remove one of those programs?).
Also, one thing I think is needed right now is an easy way for users to install programs in $HOME, only for themselves (not system-wide) and without root access. On most distros (AFAIK), you can only do "sudo apt-get install PKG" (or something similar) which installs the package system-wide for everyone, or you can go through the whole configure&&make fun to install a program in your home directory. I'd like to see something like $HOME/bin and $HOME/lib where users can auto-install binaries that only they use.
Minor details (ahem capitalized directory names ahem) aside, having a designated place for each distinct software release (/Programs/Bash/3.0/bin/) in my personal opinion looks more practical than having a separate database of package-installed files.
Unfortunately, the projects seems to be dead or nearly dead.
One thing I've never been able to figure out is where to store web-application code for webserver backends not associated with any particular vhost. I ended up deciding to package them as full "applications" under /opt, but this still feels a bit off.
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".
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.
Numeromancer suggested that you rewrite your sentence which uses "suppose" in passive voice, into active voice.
It is a school exercise at least in some European countries. It is a syntactic transformation of the sentence. Depending on the verb and other factors, the transformation preserves meaning, but sometimes it brings up a subject which was not clear in the original sentence in passive voice.
Thus, Numeromancer is suggesting a way for you to reflect on the scope of authority by using a syntactic transformation.
> 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.
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/
Etsy sounds terrible to say! Sound enough reason not to pursue that idea :-)
I know the old Bell manuals actually spelled out "et cetera" long hand in places, but still, any time i hear someone say that out loud meaning the directory, i have a (wholy irrational) cringe reaction!
These little tidbits can be amusing. Yet more often than not, void of actual technical knowledge, and with an air of arrogance, they are just a means to express superiority by proxy.
It's akin to debating Einstein on physics by belittling his accent.
It occurred to me overnight that while people may find the domain-specific conventions annoying or an attempt to convey superiority, there is actually information being conveyed by the weirdness.
For example, when I say "etsy" out loud, it makes it clear that I'm referring to the actual directory and not just saying "and other things".
It's a way to avoid a bad "who's on first" routine.
To take an example from further down in this thread: Likewise, in print, using cp and mv make it clear these specific things rather than the abstract concepts of copy and move.
A poor excuse for advancing illiteracy in both the linguistic and operational spaces. It's faster to say, but you've also made it harder for the lay person to understand. This sort of user hostility is a general problem in Linux; we are long since liberated from the days of unreliable teletype links, and the fetish for 3-letter contractions and abbreviated commands like cp and mv (instead of copy and move) does absolutely nothing to foster computer literacy.
Sorry, I didn't mean it that way. I used to love such insider knowledge as well, but over time I've become convinced that it's an anti-pattern that drives away more people than it attracts.
Computer literacy doesn't care about linguistic literacy. Every profession has their jargon.
Passwd = "password"
/usr = "slash user"
If someone doesn't understand you, then you explain and move on. But the industry has based around this jargon and removing/redefining it just creates separate standards.
Well, in 1992 when I learned it, it seemed like a long established and widespread practice. And I could hardly be blamed for not having a personal data point of the pronunciation when I was one years old. :)
If you look up "etc unix pronounciation", while there is a lot of bickering, I still think "etsy" is the slight majority among old timers. I will admit that this usage seems to have faded.
I spent some time trying to find video of any of the original Bell Labs Unix team actually saying the directory out loud--I couldn't find any. I'm going to keep searching, but they honestly seem to go out of their way to avoid it. I did find some fascinating videos along the way [1].
To my chagrin, there are a few oblique text references on the web that say indicate that within Bell Labs, it was pronounced "etcetera". But I'd still like a canonical reference.
/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.
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.
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.
/usr/games has been around since Unix v7, released in 1979. Before there were package managers, putting optional features in a designated place was the only way to conveniently control them. There were once systems that controlled access to the /usr/games directory during work or daylight hours to keep game playing from interfering with other users on the multiuser system.
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.
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?
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).
Long path names are an annoyance everywhere, from the commandline to the file browser. Use long names where appropriate ('aunt sally photos 2011' is better than 'asp11'), but for the dozen things in the root directory, there's not much effort involved.
I gather you're also not versed in the unix command line? Piping and redirecting long dir paths thru commands and arguments welcomes everything abbreviated. The mnemonics is just engineered happiness sugar-on-top of all the intrinsic greatness.
Unix/Linux/whatever should have just forbidden spaces in filenames in the first place since none of the basic tools make it easy iterate over a list of filenames with spaces correctly.
At least UNIX doesn't have a space in the path of the main programs directory (I'm looking at you Windows).
Also, many of the basic tools have a -0 option which uses the null character to replace many uses of space. Still far from an adequate solution though.
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).
Nix/NixOS (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.
