Understanding the linux filesystem (/etc, /var, /bin, /opt etc.)(tldp.org)
tldp.org
Understanding the linux filesystem (/etc, /var, /bin, /opt etc.)
http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/
17 comments
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. 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
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.
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.
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
> 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
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>
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>
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" "$@"
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:
Here is the manual:
http://plan9.bell-labs.com/7thEdMan/
Commands generally reside in directory /bin
(for binary programs). Some programs also
reside in /usr/bin, to save space in /bin.
Here is the manual:
http://plan9.bell-labs.com/7thEdMan/
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.
Arch has recently merged all binaries to unified /usr/bin directory and got rid of /bin and /sbin.
https://www.archlinux.org/news/binaries-move-to-usrbin-requi...
https://www.archlinux.org/news/binaries-move-to-usrbin-requi...
>#!/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?
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?
I prefer the simpler filesystem proposal from 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?
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?
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.
[1]: https://www.archlinux.org/news/binaries-move-to-usrbin-requi... [2]: https://wiki.archlinux.org/index.php/Arch_filesystem_hierarc...
[1]: https://www.archlinux.org/news/binaries-move-to-usrbin-requi... [2]: https://wiki.archlinux.org/index.php/Arch_filesystem_hierarc...
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 ...).
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 ...).
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.
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.
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....
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....
As for software, personally, I'm fond of GoboLinux approach: http://www.gobolinux.org/index.php?page=at_a_glance
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.
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.
The whole stali idea is pretty cool.
I was wondering recently if there could be any role for something like Docker in an experimental/radically different Linux distro.
I was wondering recently if there could be any role for something like Docker in an experimental/radically different Linux distro.
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.
Under stali, would these be in /svc?
Under stali, would these be in /svc?
Adding /devel to a location that already has /dev seems like an annoyance to the tab-completers among us.
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".
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.
> 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.
Not really a big difference in meaning or tone, if you ask me.
You didn't use “suppose”.
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!
[1] Ha!
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.
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.
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.
> 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/
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/
[deleted]
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!
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'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.
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.
Why?
Faster to say, and that's how I learned it in 1992.
This is one of those "jif" v. "gif" holy war issues. (Maybe "etc" is a minor skirmish rather than a full blown war.)
This is one of those "jif" v. "gif" holy war issues. (Maybe "etc" is a minor skirmish rather than a full blown war.)
Faster to say
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.
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.
Man you really harshed the mood on what I thought was just a cute little bit of old-timey unix lore.
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.
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.
[deleted]
Not the best of arguments. "ets", if anything, would be even faster, and "how you learned it in 1992"? Unix V5 had an etc directory in 1974 or so (http://pdp2011.sytse.net/wordpress/pdp-11/sessions/unix-v5)
Now, if Dennis told you it was pronounced etsy, you would have a point.
Now, if Dennis told you it was pronounced etsy, you would have a point.
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.
[1] Like this video from 1982, including Kernighan, Thompson, Ritchie, and Aho. http://youtu.be/tc4ROCJYbm0
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.
[1] Like this video from 1982, including Kernighan, Thompson, Ritchie, and Aho. http://youtu.be/tc4ROCJYbm0
> Not enough people know this, but when you say "etc" out loud in reference to the directory, it is supposed to sound like "etsy".
Says you. I say 'ek' and my pronunciation is just as valid.
> You can ignore those people; they probably say "exclamation mark" instead of "bang".
Bah. Everyone knows that's a shriek. You probably put sugar in your porridge.
Says you. I say 'ek' and my pronunciation is just as valid.
> You can ignore those people; they probably say "exclamation mark" instead of "bang".
Bah. Everyone knows that's a shriek. You probably put sugar in your porridge.
I wrote a utility called 'dirhelp' that can give you info on any directory:
https://github.com/jrenner/linux-directory-help
It's written in Go, binaries are available in the repo
hier(7) accomplishes largely the same thing.
This is so truly, fantastically excellent. This should be a standard system utility!
I haven't actually tried it, but that's really nifty looking.
I made something not dissimilar, which lists all the man page sections for a given term with a brief description, to help you pick the right section.
I made something not dissimilar, which lists all the man page sections for a given term with a brief description, to help you pick the right section.
mistake: I wrote 'any' directory, but that's not true. It has a limited set of information, but I tried to make it as complete as possible.
/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.
Some related articles:
20120128 http://lists.busybox.net/pipermail/busybox/2010-December/074... 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/If_I_Had_My_Own_Distro/page... http://www.osnews.com/story/3431/If_I_Had_My_Own_Distro/page... If I Had My Own Distro (Linux)
20120128 http://lists.busybox.net/pipermail/busybox/2010-December/074... 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/If_I_Had_My_Own_Distro/page... http://www.osnews.com/story/3431/If_I_Had_My_Own_Distro/page... If I Had My Own Distro (Linux)
/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.
One of my pet peeves when I work on clusters before I even mess with the fstab or ufw is always deleting this folder.
Why bother. Just leave it there.
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.
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.
You must be great at parties.
Games can go in /usr/bin or /usr/local/bin or anywhere other reasonable location. What is next, /usr/editors ? /user/browsers ? It is senseless.
/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.
/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).
Unfortunately this is obsolete in many modern distros, including Fedora and Archlinux, because of the /usr merge:
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).
Also it doesn't take /run into account (for which many distros had a hack before settling on /run).
I never understood why this hasn't been modernized. The three-letter nearly-meaningless directory names seem so obsolete.
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.
They are easy to type and do have meaning in and of themselves.
> [...] have meaning in and of themselves.
Mostly because of long usage.
Mostly because of long usage.
Unless your ssh'd into a machine, it's annoying to type long dir's. What's worse is compensating for spaces in filenames.
Thats what tab completion is for.
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!
Still sucks dealing with spaces when it comes to command processes like ffmpeg -i <no_tab>...but awesome for cd'ing or ls'ing!
Just prefix the space with a backslash. Eg: ``$ ls /foo/bar/my\ directory/``. With that backslash in place, you can continue your tab-completion.
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.
So don't put spaces in path names, it's a bitch to work with.
You can quote the space:
mkdir x\ y
cd x' 'y
Yup, that's what I do too, or %20 if its a url
[deleted]
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.
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.
Ohh yeah! This is where my initial frustrations have always been for spaces...mounting an NTFS-3G or URL encodings.
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/
Gobolinux: http://www.gobolinux.org/
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.
[deleted]
Amazing how few people I've worked with have any concept of FHS.
In FreeBSD, we have `man hier`
HIER(7) FreeBSD Miscellaneous Information Manual HIER(7)
NAME
hier — layout of file systems