8 ms·

This is what I want from Linux. Sensible & guessable names for newcomers to figure out where to put files and programs. It's frustrating having to spend time t

This is what I want from Linux. Sensible & guessable names for newcomers to figure out where to put files and programs. It's frustrating having to spend time to decide whether I should install a program in /var or /opt or /usr. What do they even mean! So, I disagree with this convention altogether and use /apps or ~/apps now.

0des 5y ago
Behold! https://en.m.wikipedia.org/wiki/Filesystem_Hierarchy_Standard https://en.m.wikipedia.org/wiki/Filesystem_Hierarchy_Standar...
- LordDragonfang 5y ago
  I feel like it just highlights the problem of how antiquated and confusing linux terminology that so many of those reference "single-user mode", used to refer to booting into root, when the vast majority of computing devices a given user will interact with only have a single actual user, making this a confusing and almost meaningless distinction to someone not already intimate familiar with linux.
- emteycz 5y ago
  Yeah, except that tells me nothing useful... The question is exactly the same: So where do I install this random binary I downloaded from the internet or compiled myself? Is it /opt, /usr/bin, /usr/local/bin, or /bin? Where do I put the dependencies I compiled for this software - /usr/lib, /usr/local/lib, /lib, /opt/lib, /opt/<app name>/lib, or what?
  - db48x 5y ago
    Wherever you want. All of the above, or none. It really is up to you.
    - emteycz 5y ago
      That's exactly the problem. This leads to mess. The Windows model of C:\Program Files\<app name> is much better.
      - drewzero1 5y ago
        Okay, but what about ProgramData? I have enough programs that put their junk in there instead of Program Files, and others that make their own directories on the root of the drive (driver installers are really bad about this). I think the best model I've seen for consistent binary locations is the 'Applications' folder in Mac OS X, but it fails as well by retaining the /usr/bin elsewhere.
      - db48x 5y ago
        No, it frees you to pick whatever unmessy solution you want. You can do `configure --prefix=/Program\ Files/<app>` if you want.
        emteycz 5y ago
        If I am not writing all of my installation scripts by hand, because that would be really intense, then every folder gets filled with random bits of software. Offering too many similar choices leads to mess. There's nothing fundamentally different between using one or more of these options and using the only option, except that in the second case there isn't any opportunity to make mess. > You can do `configure --prefix=/Program\ Files/<app>` if you want. Thanks for the tip! Can't do that with distro repo software though :-/
        db48x 5y ago
        > then every folder gets filled with random bits of software. What does that even mean? When you install something, you put it where you want it. If you don’t like where your distribution puts files, choose a different one. Not all of them use the same convention.
        emteycz 5y ago
  - aranchelk 5y ago
    I was taught /usr/local/bin /opt is for standalone packages, so if it’s a single file, no. /bin is only for stuff needed on single user mode, so probably not (unless that’s what the binary is for. /usr/bin is going to typically contain files installed by your package manager and should probably be left unaltered by human hands. The deps I would assume /usr/local/lib but it hasn’t ever come up for me.
    - krinchan 5y ago
      Fun fact: Debian is working towards[1] and Arch already has merged / and /usr. /bin is a soft link to /usr/bin and similarly with sbin and lib. [1]: https://wiki.debian.org/UsrMerge https://wiki.debian.org/UsrMerge
  - nsv 5y ago
    To add: when you install software yourself you choose this, when your install software from e.g. a distribution package it is chosen by the package maintainers, and to a larger extent the maintainers of the distribution. This is one of the big advantages of using a pre-made advantages of using a ready-made Linux distribution: beyond the convenience of having an installer or easy to install packages, you get some assurance that the system as a whole has been thoughtfully put together. Arch Linux for example symlinks /bin and /sbin to /usr/bin and /lib to /usr/lib among other things.
  - woodruffw 5y ago
    Is your account the only account that's expected to run the binary? If so, then `$HOME/bin` is a perfectly acceptable (albeit not standard) place to put it. If you expect other users to be able to execute the program, then you should put it in either `/usr/bin` or `/usr/local/bin`, depending on whether the former is already being used by a package manager. `/opt` is generally for self-contained software that doesn't play nicely with the rest of the system, but might still be installable through the default package manager.
    - megous 5y ago
      $HOME/.local is the equivalent if /usr/local for per-user stuff.
      - mananaysiempre 5y ago
        I don’t think there’s any “official” word on that (the XDG spec that defines ~/.local/share doesn’t mention ~/.local/{bin,lib} IIRC, and the traditional per-user entry in PATH seems to be ~/bin), but a fair number of people use it this way, yes, including me.
    - tom_ 5y ago
      I started out using $HOME/bin, but a fair amount of stuff assumes a /usr- or /usr/local-style folder structure when doing make install, so I've settled on using $HOME/usr/bin instead, so that programs can create $HOME/usr/include and $HOME/usr/share and whatever, without trampling on stuff in my home folder. Can't remember the last time I had a problem arranging this. If using autotools, which covers 95+% of stuff, it's usually a question of something like "./configure --prefix=$HOME/usr". (If I want to share stuff between users, /usr/local/ is of course a better place. macOS is a bit more restrictive, so I have a separate user for this, whose /usr folder is readable by everybody.)
      - woodruffw 5y ago
        Yeah, it definitely gets hairier when using anything that's more than just a drop-in binary.
  - mananaysiempre 5y ago
    The standard is, indeed, excessively vague because it was written to let many existing implementations be conformant as is, though I’d say it’s still more helpful than many other standards with that deficiency. There’s a method to it, however: - Things installed in /, if it’s different from /usr, are generally not to be touched; - Things installed in /usr are under the distro’s purview or otherwise under a package manager, any modifications are on pain of confusing it; - Things installed in /usr/local are under the admin’s purview and unmanaged one-offs, there are always some but overuse will lead to anarchy; - Things installed in /opt are for whatever is so foreign and hopeless in not conforming to the usual factoring that you just give up and put it in its own little padded cell (hello, Mathematica); - Everything is generally configured using files in /etc, possibly with the exception of some of the special snowflakes in /opt; the package manager will put config files meant to be edited there and expect the admin to merge any changes in manually, and sometimes put default settings meant to be overridden by them in /usr/share (see below)—both approaches can be problematic, but the difficulty is with migrating configuration in general, not the FHS as such. There used to be additional hierarchies like /usr/X11R6, and even a /usr/etc on some (non-Linux?) systems, but AFAIU everyone agrees their existence makes no sense (anymore?), so much that even FHS doesn’t lower itself to permitting them. The distinction between / and /usr might appear to be pointless as well, and nowadays it might be (some distros symlink them together), but previously (especially before initial ramdisks were widespread) stuff in / was whatever was needed to bring up the system enough that it could netmount a shared /usr. Inside each of /, /usr and /usr/local there is bin for things that are supposed to be directly executable, whether binary or a script and all in a single place; share and lib for other portable and non-portable (usually but not necessarily text and binary) shared files, respectively, segregated by application or purpose; finally, due to the dominance of C ABIs and APIs on Unices, the top level of lib also hosts C and C++ library files and there’s an additional directory called include for the headers required to use them. Some people also felt that putting auxiliary executables (things like cc1, the first pass of the C compiler) inside lib was awkward so they created libexec for that purpose, but I don’t think the distinction turned out to be particularly useful so not all distros maintain it. That’s it, basically. There are subtler but logical points (files vs subdiretories in /etc) and things people haven’t found an obviously superior solution for (multilib and cross environments), and I made no attempt to be historically accurate (the original separation of / and /usr happened for intensely silly reasons), but those are the fundamental principles of the system, and I feel it does make sense as a coherent implementation of a particular design. Other designs are possible (separation by application or package not purpose, Plan 9-ish overlays, NixOS’s isolated environments), but that’s a discussion on a different level; the point is that this one is at the very least internally consistent. Re the unfriendly names ... I honestly don’t know. Newbie-friendliness matters, but it’s not the only thing that does; particularly in a system intended for interactive text-mode use, concise names have a quality of their own. There’s a reason I’m more willing to reach for curl and jq rather than for httpx and lxml, for regular expressions rather than for Parsec, and even for cmd.exe, as miserable as it is, rather than for PowerShell. I feel weird that no HCI people seem to have seriously considered the tension between interactive and programmatic environments and what the text-mode user’s experience in Unix says about it, but even Tcl, which is in many ways a Bourne shell done right, loses something in casual REPL use when it eliminates (as far as idiomatic libraries are concerned) short switches. Coming up with things like rsync -avz or objdump -Ctsr is not very pleasant initially, but I certainly wouldn’t want to type out the longhand form that would be the only possible one in most programming languages (even if I find their syntax beautiful, e.g. Smalltalk/Self).
  - matheusmoreira 5y ago
    > So where do I install this random binary I downloaded from the internet or compiled myself? In your home directory.
  - graycat 5y ago
    Where? See my post to this thread at https://news.ycombinator.com/item?id=29198222 https://news.ycombinator.com/item?id=29198222
  - sergeykish 5y ago
    Follow your distribution. For example Arch Linux provides PKGBUILDs for official repos and AUR. Most of the time someone has already published PKGBUILD, but if not I just patch accordingly. And conditions that formed separation are long gone, Arch Linux symlinks most of it: /bin -> /usr/bin /sbin -> /usr/bin /usr/sbin -> /usr/bin /lib -> /usr/lib /lib64 -> /usr/lib /usr/lib64 -> /usr/lib
- somehnguy 5y ago
  I've read that a handful of times (whenever trying to figure out where to put some new random thing), and still have never come to a clear conclusion. Even better, because there are so many similar places, you might choose completely different ones depending on the day of the week and your current mood. Too much choice for things like this is harmful IMO. Deep down I truly couldn't care less where the files end up, as long as that place is the 'right' place. There are too many 'right' places which makes it hard to find random things at a later date or when on a box you're not super familiar with. It's also a complete waste of time to think about it at all.
  - NavinF 5y ago
    It’s not just you: Every distro is its own special snowflake and patches the programs they distribute to store files in a different place. The “standard” doesn’t tell you what directory structure to use inside /etc to group related config files. The “standard” doesn’t tell you where an HTTP server should serve its files. Everyone just does their own thing which makes upstream docs incorrect and useless for newcomers.
    - stryan 5y ago
      > The “standard” doesn’t tell you what directory structure to use inside /etc to group related config files. The “standard” doesn’t tell you where an HTTP server should serve its files. Everyone just does their own thing which makes upstream docs incorrect and useless for newcomers. The FHS, does actually answer both of of those questions. Files inside /etc/ should be grouped in subdirectories[0] andd the HTTP server should serve user-specified website files from /srv[1] and normal distro-provided files (such as the apache test page) from /var[2]. [0]: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s07.html#requirements1 https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s07.htm... [1]: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s17.html#purpose16a https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s17.htm... [2]: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05.html#purpose31 https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05.html#p...
      - 5y ago
chasil 5y ago
Oh, my young friend, you have no idea what POSIX has done to you. "While no one sane would put newlines in directory names, such corruption of the results could lead to exploitable vulnerabilities in scripts." http://www.etalabs.net/sh_tricks.html http://www.etalabs.net/sh_tricks.html
- oblio 5y ago
  He he. Want to see true craziness? POSIX file names are just a bag of bytes. They don't even have to be text, they can be anything (almost), there's no standard text encoding: https://lwn.net/Articles/325304/ https://lwn.net/Articles/325304/ And in typical Open Source fashion, someone actually claims it's a feature: https://lwn.net/Articles/325398/ https://lwn.net/Articles/325398/ because hey, you 99.999% percenters can suffer so that I, 0.001% percenter can implement my wacky system. https://xkcd.com/1172/ https://xkcd.com/1172/
  - chasil 5y ago
    This appears to demonstrate the full range of abuse. $ mkdir hold $ cd hold $ cat ../wildname.c #include <stdio.h> int main(int argc, char **argv) { char n[256]; int i,j=0; FILE *fp; for(i=1; i<256; i++) if(i!=47) n[j++] = i; n[j] = 0; if(fp = fopen(n, "w")) { fprintf(fp, "hello world!"); fclose(fp); } } $ cc ../wildname.c $ ./a.out $ ls -l total 16 -rw-r--r--. 1 luser lgroup 12 Nov 11 16:32 ??????????????????????????????? !"#$%&'()*+,-.0123456789:;<=>? @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? -rwxr-xr-x. 1 luser lgroup 8464 Nov 11 16:32 a.out Just because you can do something does not mean that you should.
    - oblio 5y ago
      It's software. Software's contract is the same as a legal contract. And a legal contract mostly says what you can't do. So anything not directly blocked by the software is allowed. Ergo, clear specifications, strict yet flexible types and APIs, etc. Otherwise, it's just bad design.
tenebrisalietum 5y ago
The directories that house your executables are read only to users other than root, to prevent attacks and overwriting them by non-root users. /var stands for variable data--like log files, cache directories, spool directories, etc. You shouldn't put executables there. Ideally you should be able to set the noexec flag on it. `/usr` actually exists because the original UNIX developers ran out of disk space and had to attach another disk. The difference between /bin and /usr/bin is not worth it and even Debian symlinks /usr/bin to bin. But your distribution's package manager should be putting stuff in /bin or /usr/bin, not you. Anything that follows the regex "{asterisk}/local{asterisk}" is something the system owner can do whatever with. So you should be using /usr/local/bin or $HOME/local/bin. I don't know why there's no /local off of the root. (One thing I do on my own systems is make and use an /etc/local although I think you're supposed to use something like /usr/local/etc). /opt is for third party programs that aren't installed via your distro's package manager. If you do this, any customizations you make to a system can be easily backed up by copying all dirs with local in the name. There's multiple decades of tradition behind these names, but they do date back to the age where actual teletypes were used.

0des 5y ago

Behold! https://en.m.wikipedia.org/wiki/Filesystem_Hierarchy_Standard https://en.m.wikipedia.org/wiki/Filesystem_Hierarchy_Standar...

LordDragonfang 5y ago
I feel like it just highlights the problem of how antiquated and confusing linux terminology that so many of those reference "single-user mode", used to refer to booting into root, when the vast majority of computing devices a given user will interact with only have a single actual user, making this a confusing and almost meaningless distinction to someone not already intimate familiar with linux.
emteycz 5y ago
Yeah, except that tells me nothing useful... The question is exactly the same: So where do I install this random binary I downloaded from the internet or compiled myself? Is it /opt, /usr/bin, /usr/local/bin, or /bin? Where do I put the dependencies I compiled for this software - /usr/lib, /usr/local/lib, /lib, /opt/lib, /opt/<app name>/lib, or what?
- db48x 5y ago
  Wherever you want. All of the above, or none. It really is up to you.
  - emteycz 5y ago
    That's exactly the problem. This leads to mess. The Windows model of C:\Program Files\<app name> is much better.
    - drewzero1 5y ago
      Okay, but what about ProgramData? I have enough programs that put their junk in there instead of Program Files, and others that make their own directories on the root of the drive (driver installers are really bad about this). I think the best model I've seen for consistent binary locations is the 'Applications' folder in Mac OS X, but it fails as well by retaining the /usr/bin elsewhere.
    - db48x 5y ago
      No, it frees you to pick whatever unmessy solution you want. You can do `configure --prefix=/Program\ Files/<app>` if you want.
      - emteycz 5y ago
        If I am not writing all of my installation scripts by hand, because that would be really intense, then every folder gets filled with random bits of software. Offering too many similar choices leads to mess. There's nothing fundamentally different between using one or more of these options and using the only option, except that in the second case there isn't any opportunity to make mess. > You can do `configure --prefix=/Program\ Files/<app>` if you want. Thanks for the tip! Can't do that with distro repo software though :-/
        db48x 5y ago
        > then every folder gets filled with random bits of software. What does that even mean? When you install something, you put it where you want it. If you don’t like where your distribution puts files, choose a different one. Not all of them use the same convention.
        emteycz 5y ago
- aranchelk 5y ago
  I was taught /usr/local/bin /opt is for standalone packages, so if it’s a single file, no. /bin is only for stuff needed on single user mode, so probably not (unless that’s what the binary is for. /usr/bin is going to typically contain files installed by your package manager and should probably be left unaltered by human hands. The deps I would assume /usr/local/lib but it hasn’t ever come up for me.
  - krinchan 5y ago
    Fun fact: Debian is working towards[1] and Arch already has merged / and /usr. /bin is a soft link to /usr/bin and similarly with sbin and lib. [1]: https://wiki.debian.org/UsrMerge https://wiki.debian.org/UsrMerge
- nsv 5y ago
  To add: when you install software yourself you choose this, when your install software from e.g. a distribution package it is chosen by the package maintainers, and to a larger extent the maintainers of the distribution. This is one of the big advantages of using a pre-made advantages of using a ready-made Linux distribution: beyond the convenience of having an installer or easy to install packages, you get some assurance that the system as a whole has been thoughtfully put together. Arch Linux for example symlinks /bin and /sbin to /usr/bin and /lib to /usr/lib among other things.
- woodruffw 5y ago
  Is your account the only account that's expected to run the binary? If so, then `$HOME/bin` is a perfectly acceptable (albeit not standard) place to put it. If you expect other users to be able to execute the program, then you should put it in either `/usr/bin` or `/usr/local/bin`, depending on whether the former is already being used by a package manager. `/opt` is generally for self-contained software that doesn't play nicely with the rest of the system, but might still be installable through the default package manager.
  - megous 5y ago
    $HOME/.local is the equivalent if /usr/local for per-user stuff.
    - mananaysiempre 5y ago
      I don’t think there’s any “official” word on that (the XDG spec that defines ~/.local/share doesn’t mention ~/.local/{bin,lib} IIRC, and the traditional per-user entry in PATH seems to be ~/bin), but a fair number of people use it this way, yes, including me.
  - tom_ 5y ago
    I started out using $HOME/bin, but a fair amount of stuff assumes a /usr- or /usr/local-style folder structure when doing make install, so I've settled on using $HOME/usr/bin instead, so that programs can create $HOME/usr/include and $HOME/usr/share and whatever, without trampling on stuff in my home folder. Can't remember the last time I had a problem arranging this. If using autotools, which covers 95+% of stuff, it's usually a question of something like "./configure --prefix=$HOME/usr". (If I want to share stuff between users, /usr/local/ is of course a better place. macOS is a bit more restrictive, so I have a separate user for this, whose /usr folder is readable by everybody.)
    - woodruffw 5y ago
      Yeah, it definitely gets hairier when using anything that's more than just a drop-in binary.
- mananaysiempre 5y ago
  The standard is, indeed, excessively vague because it was written to let many existing implementations be conformant as is, though I’d say it’s still more helpful than many other standards with that deficiency. There’s a method to it, however: - Things installed in /, if it’s different from /usr, are generally not to be touched; - Things installed in /usr are under the distro’s purview or otherwise under a package manager, any modifications are on pain of confusing it; - Things installed in /usr/local are under the admin’s purview and unmanaged one-offs, there are always some but overuse will lead to anarchy; - Things installed in /opt are for whatever is so foreign and hopeless in not conforming to the usual factoring that you just give up and put it in its own little padded cell (hello, Mathematica); - Everything is generally configured using files in /etc, possibly with the exception of some of the special snowflakes in /opt; the package manager will put config files meant to be edited there and expect the admin to merge any changes in manually, and sometimes put default settings meant to be overridden by them in /usr/share (see below)—both approaches can be problematic, but the difficulty is with migrating configuration in general, not the FHS as such. There used to be additional hierarchies like /usr/X11R6, and even a /usr/etc on some (non-Linux?) systems, but AFAIU everyone agrees their existence makes no sense (anymore?), so much that even FHS doesn’t lower itself to permitting them. The distinction between / and /usr might appear to be pointless as well, and nowadays it might be (some distros symlink them together), but previously (especially before initial ramdisks were widespread) stuff in / was whatever was needed to bring up the system enough that it could netmount a shared /usr. Inside each of /, /usr and /usr/local there is bin for things that are supposed to be directly executable, whether binary or a script and all in a single place; share and lib for other portable and non-portable (usually but not necessarily text and binary) shared files, respectively, segregated by application or purpose; finally, due to the dominance of C ABIs and APIs on Unices, the top level of lib also hosts C and C++ library files and there’s an additional directory called include for the headers required to use them. Some people also felt that putting auxiliary executables (things like cc1, the first pass of the C compiler) inside lib was awkward so they created libexec for that purpose, but I don’t think the distinction turned out to be particularly useful so not all distros maintain it. That’s it, basically. There are subtler but logical points (files vs subdiretories in /etc) and things people haven’t found an obviously superior solution for (multilib and cross environments), and I made no attempt to be historically accurate (the original separation of / and /usr happened for intensely silly reasons), but those are the fundamental principles of the system, and I feel it does make sense as a coherent implementation of a particular design. Other designs are possible (separation by application or package not purpose, Plan 9-ish overlays, NixOS’s isolated environments), but that’s a discussion on a different level; the point is that this one is at the very least internally consistent. Re the unfriendly names ... I honestly don’t know. Newbie-friendliness matters, but it’s not the only thing that does; particularly in a system intended for interactive text-mode use, concise names have a quality of their own. There’s a reason I’m more willing to reach for curl and jq rather than for httpx and lxml, for regular expressions rather than for Parsec, and even for cmd.exe, as miserable as it is, rather than for PowerShell. I feel weird that no HCI people seem to have seriously considered the tension between interactive and programmatic environments and what the text-mode user’s experience in Unix says about it, but even Tcl, which is in many ways a Bourne shell done right, loses something in casual REPL use when it eliminates (as far as idiomatic libraries are concerned) short switches. Coming up with things like rsync -avz or objdump -Ctsr is not very pleasant initially, but I certainly wouldn’t want to type out the longhand form that would be the only possible one in most programming languages (even if I find their syntax beautiful, e.g. Smalltalk/Self).
- matheusmoreira 5y ago
  > So where do I install this random binary I downloaded from the internet or compiled myself? In your home directory.
- graycat 5y ago
  Where? See my post to this thread at https://news.ycombinator.com/item?id=29198222 https://news.ycombinator.com/item?id=29198222
- sergeykish 5y ago
  Follow your distribution. For example Arch Linux provides PKGBUILDs for official repos and AUR. Most of the time someone has already published PKGBUILD, but if not I just patch accordingly. And conditions that formed separation are long gone, Arch Linux symlinks most of it: /bin -> /usr/bin /sbin -> /usr/bin /usr/sbin -> /usr/bin /lib -> /usr/lib /lib64 -> /usr/lib /usr/lib64 -> /usr/lib
somehnguy 5y ago
I've read that a handful of times (whenever trying to figure out where to put some new random thing), and still have never come to a clear conclusion. Even better, because there are so many similar places, you might choose completely different ones depending on the day of the week and your current mood. Too much choice for things like this is harmful IMO. Deep down I truly couldn't care less where the files end up, as long as that place is the 'right' place. There are too many 'right' places which makes it hard to find random things at a later date or when on a box you're not super familiar with. It's also a complete waste of time to think about it at all.
- NavinF 5y ago
  It’s not just you: Every distro is its own special snowflake and patches the programs they distribute to store files in a different place. The “standard” doesn’t tell you what directory structure to use inside /etc to group related config files. The “standard” doesn’t tell you where an HTTP server should serve its files. Everyone just does their own thing which makes upstream docs incorrect and useless for newcomers.
  - stryan 5y ago
    > The “standard” doesn’t tell you what directory structure to use inside /etc to group related config files. The “standard” doesn’t tell you where an HTTP server should serve its files. Everyone just does their own thing which makes upstream docs incorrect and useless for newcomers. The FHS, does actually answer both of of those questions. Files inside /etc/ should be grouped in subdirectories[0] andd the HTTP server should serve user-specified website files from /srv[1] and normal distro-provided files (such as the apache test page) from /var[2]. [0]: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s07.html#requirements1 https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s07.htm... [1]: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s17.html#purpose16a https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s17.htm... [2]: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05.html#purpose31 https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05.html#p...
    - 5y ago

chasil 5y ago

Oh, my young friend, you have no idea what POSIX has done to you. "While no one sane would put newlines in directory names, such corruption of the results could lead to exploitable vulnerabilities in scripts." http://www.etalabs.net/sh_tricks.html http://www.etalabs.net/sh_tricks.html

oblio 5y ago
He he. Want to see true craziness? POSIX file names are just a bag of bytes. They don't even have to be text, they can be anything (almost), there's no standard text encoding: https://lwn.net/Articles/325304/ https://lwn.net/Articles/325304/ And in typical Open Source fashion, someone actually claims it's a feature: https://lwn.net/Articles/325398/ https://lwn.net/Articles/325398/ because hey, you 99.999% percenters can suffer so that I, 0.001% percenter can implement my wacky system. https://xkcd.com/1172/ https://xkcd.com/1172/
- chasil 5y ago
  This appears to demonstrate the full range of abuse. $ mkdir hold $ cd hold $ cat ../wildname.c #include <stdio.h> int main(int argc, char **argv) { char n[256]; int i,j=0; FILE *fp; for(i=1; i<256; i++) if(i!=47) n[j++] = i; n[j] = 0; if(fp = fopen(n, "w")) { fprintf(fp, "hello world!"); fclose(fp); } } $ cc ../wildname.c $ ./a.out $ ls -l total 16 -rw-r--r--. 1 luser lgroup 12 Nov 11 16:32 ??????????????????????????????? !"#$%&'()*+,-.0123456789:;<=>? @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? -rwxr-xr-x. 1 luser lgroup 8464 Nov 11 16:32 a.out Just because you can do something does not mean that you should.
  - oblio 5y ago
    It's software. Software's contract is the same as a legal contract. And a legal contract mostly says what you can't do. So anything not directly blocked by the software is allowed. Ergo, clear specifications, strict yet flexible types and APIs, etc. Otherwise, it's just bad design.

tenebrisalietum 5y ago

The directories that house your executables are read only to users other than root, to prevent attacks and overwriting them by non-root users. /var stands for variable data--like log files, cache directories, spool directories, etc. You shouldn't put executables there. Ideally you should be able to set the noexec flag on it. `/usr` actually exists because the original UNIX developers ran out of disk space and had to attach another disk. The difference between /bin and /usr/bin is not worth it and even Debian symlinks /usr/bin to bin. But your distribution's package manager should be putting stuff in /bin or /usr/bin, not you. Anything that follows the regex "{asterisk}/local{asterisk}" is something the system owner can do whatever with. So you should be using /usr/local/bin or $HOME/local/bin. I don't know why there's no /local off of the root. (One thing I do on my own systems is make and use an /etc/local although I think you're supposed to use something like /usr/local/etc). /opt is for third party programs that aren't installed via your distro's package manager. If you do this, any customizations you make to a system can be easily backed up by copying all dirs with local in the name. There's multiple decades of tradition behind these names, but they do date back to the age where actual teletypes were used.