What is /usr/local/bin?












80















Before today, I've used the terminal to a limited extent of moving in and out of directories and changing the dates of files using the touch command. I had realised the full extent of the terminal after installing a fun script on Mac and having to chmod 755 the file to make it executable afterwards.



I'd like to know what /usr/local/bin is, though. /usr/, I assume, is the user of the computer. I'm not sure why /local/ is there, though. It obviously stands for the local computer, but since it's on the computer (or a server), would it really be necessary? Wouldn't /usr/bin be fine?



And what is /bin? Why is this area usually used for installing scripts onto the terminal?










share|improve this question





























    80















    Before today, I've used the terminal to a limited extent of moving in and out of directories and changing the dates of files using the touch command. I had realised the full extent of the terminal after installing a fun script on Mac and having to chmod 755 the file to make it executable afterwards.



    I'd like to know what /usr/local/bin is, though. /usr/, I assume, is the user of the computer. I'm not sure why /local/ is there, though. It obviously stands for the local computer, but since it's on the computer (or a server), would it really be necessary? Wouldn't /usr/bin be fine?



    And what is /bin? Why is this area usually used for installing scripts onto the terminal?










    share|improve this question



























      80












      80








      80


      28






      Before today, I've used the terminal to a limited extent of moving in and out of directories and changing the dates of files using the touch command. I had realised the full extent of the terminal after installing a fun script on Mac and having to chmod 755 the file to make it executable afterwards.



      I'd like to know what /usr/local/bin is, though. /usr/, I assume, is the user of the computer. I'm not sure why /local/ is there, though. It obviously stands for the local computer, but since it's on the computer (or a server), would it really be necessary? Wouldn't /usr/bin be fine?



      And what is /bin? Why is this area usually used for installing scripts onto the terminal?










      share|improve this question
















      Before today, I've used the terminal to a limited extent of moving in and out of directories and changing the dates of files using the touch command. I had realised the full extent of the terminal after installing a fun script on Mac and having to chmod 755 the file to make it executable afterwards.



      I'd like to know what /usr/local/bin is, though. /usr/, I assume, is the user of the computer. I'm not sure why /local/ is there, though. It obviously stands for the local computer, but since it's on the computer (or a server), would it really be necessary? Wouldn't /usr/bin be fine?



      And what is /bin? Why is this area usually used for installing scripts onto the terminal?







      executable directory-structure






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 2 '15 at 5:16









      Thomas Weinbrenner

      2,66721131




      2,66721131










      asked Nov 18 '10 at 13:49









      JFWJFW

      8071911




      8071911






















          9 Answers
          9






          active

          oldest

          votes


















          72














          /usr/local/bin is for programs that a normal user may run.




          • The /usr/local hierarchy is for use by the system administrator when installing software locally.

          • It needs to be safe from being overwritten when the system software is updated.

          • It may be used for programs and data that
            are shareable amongst a group of hosts, but not found in /usr.

          • Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to
            replace or upgrade software in /usr.


          This source helps explain the filesystem hierarchy standard on a deeper level.



          You might find this article on the use and abuse of /usr/local/bin interesting as well.






          share|improve this answer


























          • """unless it is being installed to replace or upgrade software in /usr""" meaning?

            – Pacerier
            Nov 1 '17 at 21:35



















          53















          /usr/, I assume is the user of the computer.




          Close.



          Unix started out as a multi-user operating system, so it's not "the user," it's "the users," plural.



          Before AT&T Unix System V Release 4 (SVR4) came out in 1988 with its user management tools defaulting to creating user home directories in /home, the conventional location was /usr.¹ Your $HOME directory might have been /usr/jfw on a System III box.



          /usr also contained, then as now, /usr/bin, /usr/lib, etc. Experience showed that segregating the home directories was good system management practice, so with the /home policy change in SVR4, it left behind everything we now think of as belonging in /usr.



          /usr still had a good reason to hold onto the name: what got left behind were files that didn't need to be available until the system was booted up far enough to support normal interactive use. That is to say, what was left behind were the user-focused parts of the OS. This meant that /usr could be on a different physical volume, which was a good thing back in the days of 92 MB hard disk drives the size of washing machines.



          Early Unix systems were careful to keep the core OS files out of /usr so that you could still boot into single-user mode² even if the /usr volume was unmountable for some reason. The root volume contained sufficient tools to get the /usr volume back online.



          Several Unix flavors now disregard this old design principle since even small embedded systems have enough room for both the traditional root volume files and all of /usr on a single volume.³ Red Hat Enterprise Linux, Solaris and Cygwin symlink /bin to /usr/bin and /lib to /usr/lib so that there is no longer any difference between these directories.




          .../local/...obviously stands for the local computer...




          Yes. It refers to the fact that files under /usr/local are supposed to be particular to that single system. Files that are in any way generic should live elsewhere.



          This also has roots in the way Unix systems were commonly used decades ago when all this was standardized. Again, hard disks of the time were bulky, really expensive, and stored little by today's standards. To save money and space on disks, a computer lab full of Unix boxes would often share most of /usr over NFS or some other network file sharing protocol, so each box didn't have to have its own redundant copy.⁴ Files specific to a single box would go under /usr/local, which would be a separate volume from /usr.



          This historical heritage is why it's still the default for most third-party Unix software to install into /usr/local when installed by hand. Most such software will let you install the package somewhere else, but by making a non-choice, you get the safe default, which doesn't interfere with other common install locations with more specific purposes.



          There are good reasons to make software install somewhere else instead. Apple's macOS team does this when they build, say, bash from the GNU Bash source code. They use / as the installation prefix, overriding the /usr/local default, so that Bash ends up in /bin.



          Another example is the way older Linux systems segregated their GUI software into /usr/X11R6, to keep it separate from the traditional command line and curses-based software. This was done simply by overriding the default /usr/local prefix with /usr/X11R6.⁵




          And what is /bin?




          It's short for "binary," which in this context means "a file that is not plain text." Most such files are executables on a Unix box, so these two terms have become synonymous in some circles. ("Please build me a binary for RHEL 7, Fred.")



          Text files on a Unix box live elsewhere: /etc, /usr/include, /usr/share, etc.



          Once upon a time, even shell scripts — which are plain text files — were kept out of bin directories, but this line, too, has blurred. Today, bin directories typically contain any kind of executable file, whether strictly "binary" or not.⁶





          Footnotes and Digressions:





          1. The primitive nature of the user management tools prior to SVR4 meant that the HOME=/usr/$NAME scheme was merely documented as a convention, rather than enforced by software tools as a default.



            You can see this on page 4-8 of the "AT&T Unix System V Release 3.2 System Administrator's Guide: here you see AT&T recommending the old /usr/$NAME scheme in the last major version of Unix before SVR4 came out.



            It was fairly common in older Unix systems for the system administrators to choose a different scheme that made more sense to them. People being people, that meant a lot of different schemes got invented.



            One scheme I came across before /home/$NAME became the standard was /u/$NAME.



            Another system I used in the early 1990s had so many users that they couldn't fit all the home directories onto a single physical volume, so they used a scheme like /u1/$NAME, /u2/$NAME, and so on, as I recall. Which disk your home directory ended up on was simply a matter of which one had space on it at the time your account was created.




          2. You can boot a macOS box into single-user mode by holding down Cmd-S while it boots. Let go once the screen turns black and you see light gray text appear. It's like running under the Terminal, but it takes over the whole screen because the GUI hasn't started yet.



            Be careful, you're running as root.



            Type "exit" at the single-user root prompt to leave single-user mode and continue booting into multi-user GUI mode.




          3. Unixy OSes that still appear to keep critical single-user mode files out of /usr may not, in fact, do so these days. I once rendered a FreeBSD 9 box unbootable by moving /usr to a ZFS volume. I forgot that the ZFS-on-root features didn't land until FreeBSD 10, creating a Catch 22: the OS needed files in /usr in order to mount /usr!



            That was bad enough, but if FreeBSD 9 were still keeping its single-user boot stuff out of /usr, I could have fixed it in place. Since it wouldn't boot even to single-user mode with /usr being unmountable, clearly that tradition had been violated somehow. I had to boot from a rescue CD to get that system back up again.



          4. This is also where we get /usr/share: it segregates files that could be shared even between Unix boxes with different processor types. Typically, text files: man pages, the dictionary, etc.


          5. "X11R6" referred to the version of the X Window System underpinning Linux GUIs at the time this convention was prevalent. Linux systems generally stopped segregating the GUI software about the time X11R6 was replaced with X.Org.


          6. The original Unix systems kept their core shell scripts in /etc in order to avoid commingling them with the true binaries in /bin.







          share|improve this answer





















          • 1





            Loved that picture of washing machine!

            – asgs
            Oct 12 '17 at 20:18











          • @Warren, What are the notable OSes before System III?

            – Pacerier
            Nov 1 '17 at 20:59











          • @Pacerier: UNIX Versions 1 through 7, UNIX/32V, 1BSD through 4BSD not including the dot releases of 4BSD (4.1BSD was roughly contemporaneous with AT&T Unix System III), and PWB Unix. Source. Why do you ask, and what does it have to do with this question?

            – Warren Young
            Nov 1 '17 at 21:33











          • @Warren, Well, they might have affected the defacto "directory naming system" somehow

            – Pacerier
            Nov 1 '17 at 21:34













          • @Pacerier: I'll stand by my claim: there was no "standard" before System V, only conventions and local practices.

            – Warren Young
            Nov 1 '17 at 21:35



















          9














          I would recommend referring to Wikipedia for structure related questions in general, it will cover the basics.



          To answer your question directly, however:




          • /usr is, loosely, non-critical system libraries and executables

          • /usr/local is, again loosely, for non-system libraries and executables


          This is why you tend to find similar structure between the two; /usr/{,local/}{bin,sbin,lib}. Being new to the shell, that bit with the {}'s is a shell expansion. Try executing



          ls -ld /usr/{,local/}{bin,sbin,lib}


          from your local shell to see how it works.






          share|improve this answer































            8














            /usr/local/bin shows the UNIX-esque roots of the latest Mac OS (its BSD based under there).




            • "usr" stands for UNIX System Resources. This is the location that system programs and libraries are stored.

            • "local" represents resources that were not shipped with the standard distribution and, usually, compiled and maintained on a per site basis.

            • "bin" represents binary compiled executables.


            This has morphed since the early implementations of UNIX to Linux and BSD, but the convention has stayed. Now, /usr/bin would be for "main" or core programs and libraries where /usr/local/bin would be for add-on and non-critical programs and libraries.






            share|improve this answer





















            • 11





              I've been using Unix since shortly after the Berlin Wall fell, and I'd never heard the "Unix System Resources" expansion for "usr" until today; it is a backronym. "usr" got its name because it's where the user home directories were originally located. That is, if you had a login on an old System III box, your initial working directory would be /usr/nzwulfin by default. Another common scheme. before the SVR4 /home scheme took over, was /u. One system I used early on had so many users they needed multiple physical disks for user file storage, so they had things like /u/d5/tangent.

              – Warren Young
              Nov 18 '10 at 17:54






            • 3





              @Warren I hadn't heard it either and poked around Google for a while; it sounds like there are quite a few backronyms

              – Michael Mrozek
              Nov 19 '10 at 23:35



















            4














            /usr/local/bin is the most popular default location for executable files, especially open source ones.



            This is however arguably a poor choice as, on Unix systems, /usr has been standardized in the early nineties to contain a hierarchy of files that belong to the operating system and thus can be shared by multiple systems using that OS.



            As these files are static, the /usr file system can be mounted read-only. /usr/local is defeating this standard as it is by design local thus non shared, so needs to be read-write to allow local compilation and isn't part of the operating system. Too bad something like /opt/local wasn't chosen instead ...






            share|improve this answer

































              1














              On a Mac, while you can only write to /usr as root so Terminal, there is the way to go there in Finder. Use the "Go To Folder..."command under the "Go" menu.






              share|improve this answer































                1














                I recommend you use /usr/local for commercial programs you might install such as Mathematica. Place it in its own partition when you set up. When you upgrade your OS, this partition won't be disturbed and you won't have to re-install its contents. So use it for stuff you want to keep between OS upgrades.



                Separately, make sure you give /home its own partition for this reason too.






                share|improve this answer

































                  0














                  This answer might be helpful as well.



                  /usr/local



                  The original idea behind /usr/local was to have a separate ('local') '/usr' directory on every machine besides /usr, which might be just mounted read-only from somewhere else. It copies the structure of /usr.



                  These days, /usr/local is widely regarded as a good place in which to keep self-compiled or third-party programs. The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated.



                  It may be used for programs and data that are shared among a group of hosts, but not found in /usr. Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr.






                  share|improve this answer

































                    0














                    usr==user?
                    I think usr stands for Unix System Resource





                    share








                    New contributor




                    Aliar is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                    Check out our Code of Conduct.




















                      Your Answer








                      StackExchange.ready(function() {
                      var channelOptions = {
                      tags: "".split(" "),
                      id: "106"
                      };
                      initTagRenderer("".split(" "), "".split(" "), channelOptions);

                      StackExchange.using("externalEditor", function() {
                      // Have to fire editor after snippets, if snippets enabled
                      if (StackExchange.settings.snippets.snippetsEnabled) {
                      StackExchange.using("snippets", function() {
                      createEditor();
                      });
                      }
                      else {
                      createEditor();
                      }
                      });

                      function createEditor() {
                      StackExchange.prepareEditor({
                      heartbeatType: 'answer',
                      autoActivateHeartbeat: false,
                      convertImagesToLinks: false,
                      noModals: true,
                      showLowRepImageUploadWarning: true,
                      reputationToPostImages: null,
                      bindNavPrevention: true,
                      postfix: "",
                      imageUploader: {
                      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
                      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
                      allowUrls: true
                      },
                      onDemand: true,
                      discardSelector: ".discard-answer"
                      ,immediatelyShowMarkdownHelp:true
                      });


                      }
                      });














                      draft saved

                      draft discarded


















                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f4186%2fwhat-is-usr-local-bin%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown

























                      9 Answers
                      9






                      active

                      oldest

                      votes








                      9 Answers
                      9






                      active

                      oldest

                      votes









                      active

                      oldest

                      votes






                      active

                      oldest

                      votes









                      72














                      /usr/local/bin is for programs that a normal user may run.




                      • The /usr/local hierarchy is for use by the system administrator when installing software locally.

                      • It needs to be safe from being overwritten when the system software is updated.

                      • It may be used for programs and data that
                        are shareable amongst a group of hosts, but not found in /usr.

                      • Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to
                        replace or upgrade software in /usr.


                      This source helps explain the filesystem hierarchy standard on a deeper level.



                      You might find this article on the use and abuse of /usr/local/bin interesting as well.






                      share|improve this answer


























                      • """unless it is being installed to replace or upgrade software in /usr""" meaning?

                        – Pacerier
                        Nov 1 '17 at 21:35
















                      72














                      /usr/local/bin is for programs that a normal user may run.




                      • The /usr/local hierarchy is for use by the system administrator when installing software locally.

                      • It needs to be safe from being overwritten when the system software is updated.

                      • It may be used for programs and data that
                        are shareable amongst a group of hosts, but not found in /usr.

                      • Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to
                        replace or upgrade software in /usr.


                      This source helps explain the filesystem hierarchy standard on a deeper level.



                      You might find this article on the use and abuse of /usr/local/bin interesting as well.






                      share|improve this answer


























                      • """unless it is being installed to replace or upgrade software in /usr""" meaning?

                        – Pacerier
                        Nov 1 '17 at 21:35














                      72












                      72








                      72







                      /usr/local/bin is for programs that a normal user may run.




                      • The /usr/local hierarchy is for use by the system administrator when installing software locally.

                      • It needs to be safe from being overwritten when the system software is updated.

                      • It may be used for programs and data that
                        are shareable amongst a group of hosts, but not found in /usr.

                      • Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to
                        replace or upgrade software in /usr.


                      This source helps explain the filesystem hierarchy standard on a deeper level.



                      You might find this article on the use and abuse of /usr/local/bin interesting as well.






                      share|improve this answer















                      /usr/local/bin is for programs that a normal user may run.




                      • The /usr/local hierarchy is for use by the system administrator when installing software locally.

                      • It needs to be safe from being overwritten when the system software is updated.

                      • It may be used for programs and data that
                        are shareable amongst a group of hosts, but not found in /usr.

                      • Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to
                        replace or upgrade software in /usr.


                      This source helps explain the filesystem hierarchy standard on a deeper level.



                      You might find this article on the use and abuse of /usr/local/bin interesting as well.







                      share|improve this answer














                      share|improve this answer



                      share|improve this answer








                      edited Nov 13 '14 at 6:56









                      JakeGould

                      1698




                      1698










                      answered Nov 18 '10 at 14:09









                      iamsidiamsid

                      1,8161817




                      1,8161817













                      • """unless it is being installed to replace or upgrade software in /usr""" meaning?

                        – Pacerier
                        Nov 1 '17 at 21:35



















                      • """unless it is being installed to replace or upgrade software in /usr""" meaning?

                        – Pacerier
                        Nov 1 '17 at 21:35

















                      """unless it is being installed to replace or upgrade software in /usr""" meaning?

                      – Pacerier
                      Nov 1 '17 at 21:35





                      """unless it is being installed to replace or upgrade software in /usr""" meaning?

                      – Pacerier
                      Nov 1 '17 at 21:35













                      53















                      /usr/, I assume is the user of the computer.




                      Close.



                      Unix started out as a multi-user operating system, so it's not "the user," it's "the users," plural.



                      Before AT&T Unix System V Release 4 (SVR4) came out in 1988 with its user management tools defaulting to creating user home directories in /home, the conventional location was /usr.¹ Your $HOME directory might have been /usr/jfw on a System III box.



                      /usr also contained, then as now, /usr/bin, /usr/lib, etc. Experience showed that segregating the home directories was good system management practice, so with the /home policy change in SVR4, it left behind everything we now think of as belonging in /usr.



                      /usr still had a good reason to hold onto the name: what got left behind were files that didn't need to be available until the system was booted up far enough to support normal interactive use. That is to say, what was left behind were the user-focused parts of the OS. This meant that /usr could be on a different physical volume, which was a good thing back in the days of 92 MB hard disk drives the size of washing machines.



                      Early Unix systems were careful to keep the core OS files out of /usr so that you could still boot into single-user mode² even if the /usr volume was unmountable for some reason. The root volume contained sufficient tools to get the /usr volume back online.



                      Several Unix flavors now disregard this old design principle since even small embedded systems have enough room for both the traditional root volume files and all of /usr on a single volume.³ Red Hat Enterprise Linux, Solaris and Cygwin symlink /bin to /usr/bin and /lib to /usr/lib so that there is no longer any difference between these directories.




                      .../local/...obviously stands for the local computer...




                      Yes. It refers to the fact that files under /usr/local are supposed to be particular to that single system. Files that are in any way generic should live elsewhere.



                      This also has roots in the way Unix systems were commonly used decades ago when all this was standardized. Again, hard disks of the time were bulky, really expensive, and stored little by today's standards. To save money and space on disks, a computer lab full of Unix boxes would often share most of /usr over NFS or some other network file sharing protocol, so each box didn't have to have its own redundant copy.⁴ Files specific to a single box would go under /usr/local, which would be a separate volume from /usr.



                      This historical heritage is why it's still the default for most third-party Unix software to install into /usr/local when installed by hand. Most such software will let you install the package somewhere else, but by making a non-choice, you get the safe default, which doesn't interfere with other common install locations with more specific purposes.



                      There are good reasons to make software install somewhere else instead. Apple's macOS team does this when they build, say, bash from the GNU Bash source code. They use / as the installation prefix, overriding the /usr/local default, so that Bash ends up in /bin.



                      Another example is the way older Linux systems segregated their GUI software into /usr/X11R6, to keep it separate from the traditional command line and curses-based software. This was done simply by overriding the default /usr/local prefix with /usr/X11R6.⁵




                      And what is /bin?




                      It's short for "binary," which in this context means "a file that is not plain text." Most such files are executables on a Unix box, so these two terms have become synonymous in some circles. ("Please build me a binary for RHEL 7, Fred.")



                      Text files on a Unix box live elsewhere: /etc, /usr/include, /usr/share, etc.



                      Once upon a time, even shell scripts — which are plain text files — were kept out of bin directories, but this line, too, has blurred. Today, bin directories typically contain any kind of executable file, whether strictly "binary" or not.⁶





                      Footnotes and Digressions:





                      1. The primitive nature of the user management tools prior to SVR4 meant that the HOME=/usr/$NAME scheme was merely documented as a convention, rather than enforced by software tools as a default.



                        You can see this on page 4-8 of the "AT&T Unix System V Release 3.2 System Administrator's Guide: here you see AT&T recommending the old /usr/$NAME scheme in the last major version of Unix before SVR4 came out.



                        It was fairly common in older Unix systems for the system administrators to choose a different scheme that made more sense to them. People being people, that meant a lot of different schemes got invented.



                        One scheme I came across before /home/$NAME became the standard was /u/$NAME.



                        Another system I used in the early 1990s had so many users that they couldn't fit all the home directories onto a single physical volume, so they used a scheme like /u1/$NAME, /u2/$NAME, and so on, as I recall. Which disk your home directory ended up on was simply a matter of which one had space on it at the time your account was created.




                      2. You can boot a macOS box into single-user mode by holding down Cmd-S while it boots. Let go once the screen turns black and you see light gray text appear. It's like running under the Terminal, but it takes over the whole screen because the GUI hasn't started yet.



                        Be careful, you're running as root.



                        Type "exit" at the single-user root prompt to leave single-user mode and continue booting into multi-user GUI mode.




                      3. Unixy OSes that still appear to keep critical single-user mode files out of /usr may not, in fact, do so these days. I once rendered a FreeBSD 9 box unbootable by moving /usr to a ZFS volume. I forgot that the ZFS-on-root features didn't land until FreeBSD 10, creating a Catch 22: the OS needed files in /usr in order to mount /usr!



                        That was bad enough, but if FreeBSD 9 were still keeping its single-user boot stuff out of /usr, I could have fixed it in place. Since it wouldn't boot even to single-user mode with /usr being unmountable, clearly that tradition had been violated somehow. I had to boot from a rescue CD to get that system back up again.



                      4. This is also where we get /usr/share: it segregates files that could be shared even between Unix boxes with different processor types. Typically, text files: man pages, the dictionary, etc.


                      5. "X11R6" referred to the version of the X Window System underpinning Linux GUIs at the time this convention was prevalent. Linux systems generally stopped segregating the GUI software about the time X11R6 was replaced with X.Org.


                      6. The original Unix systems kept their core shell scripts in /etc in order to avoid commingling them with the true binaries in /bin.







                      share|improve this answer





















                      • 1





                        Loved that picture of washing machine!

                        – asgs
                        Oct 12 '17 at 20:18











                      • @Warren, What are the notable OSes before System III?

                        – Pacerier
                        Nov 1 '17 at 20:59











                      • @Pacerier: UNIX Versions 1 through 7, UNIX/32V, 1BSD through 4BSD not including the dot releases of 4BSD (4.1BSD was roughly contemporaneous with AT&T Unix System III), and PWB Unix. Source. Why do you ask, and what does it have to do with this question?

                        – Warren Young
                        Nov 1 '17 at 21:33











                      • @Warren, Well, they might have affected the defacto "directory naming system" somehow

                        – Pacerier
                        Nov 1 '17 at 21:34













                      • @Pacerier: I'll stand by my claim: there was no "standard" before System V, only conventions and local practices.

                        – Warren Young
                        Nov 1 '17 at 21:35
















                      53















                      /usr/, I assume is the user of the computer.




                      Close.



                      Unix started out as a multi-user operating system, so it's not "the user," it's "the users," plural.



                      Before AT&T Unix System V Release 4 (SVR4) came out in 1988 with its user management tools defaulting to creating user home directories in /home, the conventional location was /usr.¹ Your $HOME directory might have been /usr/jfw on a System III box.



                      /usr also contained, then as now, /usr/bin, /usr/lib, etc. Experience showed that segregating the home directories was good system management practice, so with the /home policy change in SVR4, it left behind everything we now think of as belonging in /usr.



                      /usr still had a good reason to hold onto the name: what got left behind were files that didn't need to be available until the system was booted up far enough to support normal interactive use. That is to say, what was left behind were the user-focused parts of the OS. This meant that /usr could be on a different physical volume, which was a good thing back in the days of 92 MB hard disk drives the size of washing machines.



                      Early Unix systems were careful to keep the core OS files out of /usr so that you could still boot into single-user mode² even if the /usr volume was unmountable for some reason. The root volume contained sufficient tools to get the /usr volume back online.



                      Several Unix flavors now disregard this old design principle since even small embedded systems have enough room for both the traditional root volume files and all of /usr on a single volume.³ Red Hat Enterprise Linux, Solaris and Cygwin symlink /bin to /usr/bin and /lib to /usr/lib so that there is no longer any difference between these directories.




                      .../local/...obviously stands for the local computer...




                      Yes. It refers to the fact that files under /usr/local are supposed to be particular to that single system. Files that are in any way generic should live elsewhere.



                      This also has roots in the way Unix systems were commonly used decades ago when all this was standardized. Again, hard disks of the time were bulky, really expensive, and stored little by today's standards. To save money and space on disks, a computer lab full of Unix boxes would often share most of /usr over NFS or some other network file sharing protocol, so each box didn't have to have its own redundant copy.⁴ Files specific to a single box would go under /usr/local, which would be a separate volume from /usr.



                      This historical heritage is why it's still the default for most third-party Unix software to install into /usr/local when installed by hand. Most such software will let you install the package somewhere else, but by making a non-choice, you get the safe default, which doesn't interfere with other common install locations with more specific purposes.



                      There are good reasons to make software install somewhere else instead. Apple's macOS team does this when they build, say, bash from the GNU Bash source code. They use / as the installation prefix, overriding the /usr/local default, so that Bash ends up in /bin.



                      Another example is the way older Linux systems segregated their GUI software into /usr/X11R6, to keep it separate from the traditional command line and curses-based software. This was done simply by overriding the default /usr/local prefix with /usr/X11R6.⁵




                      And what is /bin?




                      It's short for "binary," which in this context means "a file that is not plain text." Most such files are executables on a Unix box, so these two terms have become synonymous in some circles. ("Please build me a binary for RHEL 7, Fred.")



                      Text files on a Unix box live elsewhere: /etc, /usr/include, /usr/share, etc.



                      Once upon a time, even shell scripts — which are plain text files — were kept out of bin directories, but this line, too, has blurred. Today, bin directories typically contain any kind of executable file, whether strictly "binary" or not.⁶





                      Footnotes and Digressions:





                      1. The primitive nature of the user management tools prior to SVR4 meant that the HOME=/usr/$NAME scheme was merely documented as a convention, rather than enforced by software tools as a default.



                        You can see this on page 4-8 of the "AT&T Unix System V Release 3.2 System Administrator's Guide: here you see AT&T recommending the old /usr/$NAME scheme in the last major version of Unix before SVR4 came out.



                        It was fairly common in older Unix systems for the system administrators to choose a different scheme that made more sense to them. People being people, that meant a lot of different schemes got invented.



                        One scheme I came across before /home/$NAME became the standard was /u/$NAME.



                        Another system I used in the early 1990s had so many users that they couldn't fit all the home directories onto a single physical volume, so they used a scheme like /u1/$NAME, /u2/$NAME, and so on, as I recall. Which disk your home directory ended up on was simply a matter of which one had space on it at the time your account was created.




                      2. You can boot a macOS box into single-user mode by holding down Cmd-S while it boots. Let go once the screen turns black and you see light gray text appear. It's like running under the Terminal, but it takes over the whole screen because the GUI hasn't started yet.



                        Be careful, you're running as root.



                        Type "exit" at the single-user root prompt to leave single-user mode and continue booting into multi-user GUI mode.




                      3. Unixy OSes that still appear to keep critical single-user mode files out of /usr may not, in fact, do so these days. I once rendered a FreeBSD 9 box unbootable by moving /usr to a ZFS volume. I forgot that the ZFS-on-root features didn't land until FreeBSD 10, creating a Catch 22: the OS needed files in /usr in order to mount /usr!



                        That was bad enough, but if FreeBSD 9 were still keeping its single-user boot stuff out of /usr, I could have fixed it in place. Since it wouldn't boot even to single-user mode with /usr being unmountable, clearly that tradition had been violated somehow. I had to boot from a rescue CD to get that system back up again.



                      4. This is also where we get /usr/share: it segregates files that could be shared even between Unix boxes with different processor types. Typically, text files: man pages, the dictionary, etc.


                      5. "X11R6" referred to the version of the X Window System underpinning Linux GUIs at the time this convention was prevalent. Linux systems generally stopped segregating the GUI software about the time X11R6 was replaced with X.Org.


                      6. The original Unix systems kept their core shell scripts in /etc in order to avoid commingling them with the true binaries in /bin.







                      share|improve this answer





















                      • 1





                        Loved that picture of washing machine!

                        – asgs
                        Oct 12 '17 at 20:18











                      • @Warren, What are the notable OSes before System III?

                        – Pacerier
                        Nov 1 '17 at 20:59











                      • @Pacerier: UNIX Versions 1 through 7, UNIX/32V, 1BSD through 4BSD not including the dot releases of 4BSD (4.1BSD was roughly contemporaneous with AT&T Unix System III), and PWB Unix. Source. Why do you ask, and what does it have to do with this question?

                        – Warren Young
                        Nov 1 '17 at 21:33











                      • @Warren, Well, they might have affected the defacto "directory naming system" somehow

                        – Pacerier
                        Nov 1 '17 at 21:34













                      • @Pacerier: I'll stand by my claim: there was no "standard" before System V, only conventions and local practices.

                        – Warren Young
                        Nov 1 '17 at 21:35














                      53












                      53








                      53








                      /usr/, I assume is the user of the computer.




                      Close.



                      Unix started out as a multi-user operating system, so it's not "the user," it's "the users," plural.



                      Before AT&T Unix System V Release 4 (SVR4) came out in 1988 with its user management tools defaulting to creating user home directories in /home, the conventional location was /usr.¹ Your $HOME directory might have been /usr/jfw on a System III box.



                      /usr also contained, then as now, /usr/bin, /usr/lib, etc. Experience showed that segregating the home directories was good system management practice, so with the /home policy change in SVR4, it left behind everything we now think of as belonging in /usr.



                      /usr still had a good reason to hold onto the name: what got left behind were files that didn't need to be available until the system was booted up far enough to support normal interactive use. That is to say, what was left behind were the user-focused parts of the OS. This meant that /usr could be on a different physical volume, which was a good thing back in the days of 92 MB hard disk drives the size of washing machines.



                      Early Unix systems were careful to keep the core OS files out of /usr so that you could still boot into single-user mode² even if the /usr volume was unmountable for some reason. The root volume contained sufficient tools to get the /usr volume back online.



                      Several Unix flavors now disregard this old design principle since even small embedded systems have enough room for both the traditional root volume files and all of /usr on a single volume.³ Red Hat Enterprise Linux, Solaris and Cygwin symlink /bin to /usr/bin and /lib to /usr/lib so that there is no longer any difference between these directories.




                      .../local/...obviously stands for the local computer...




                      Yes. It refers to the fact that files under /usr/local are supposed to be particular to that single system. Files that are in any way generic should live elsewhere.



                      This also has roots in the way Unix systems were commonly used decades ago when all this was standardized. Again, hard disks of the time were bulky, really expensive, and stored little by today's standards. To save money and space on disks, a computer lab full of Unix boxes would often share most of /usr over NFS or some other network file sharing protocol, so each box didn't have to have its own redundant copy.⁴ Files specific to a single box would go under /usr/local, which would be a separate volume from /usr.



                      This historical heritage is why it's still the default for most third-party Unix software to install into /usr/local when installed by hand. Most such software will let you install the package somewhere else, but by making a non-choice, you get the safe default, which doesn't interfere with other common install locations with more specific purposes.



                      There are good reasons to make software install somewhere else instead. Apple's macOS team does this when they build, say, bash from the GNU Bash source code. They use / as the installation prefix, overriding the /usr/local default, so that Bash ends up in /bin.



                      Another example is the way older Linux systems segregated their GUI software into /usr/X11R6, to keep it separate from the traditional command line and curses-based software. This was done simply by overriding the default /usr/local prefix with /usr/X11R6.⁵




                      And what is /bin?




                      It's short for "binary," which in this context means "a file that is not plain text." Most such files are executables on a Unix box, so these two terms have become synonymous in some circles. ("Please build me a binary for RHEL 7, Fred.")



                      Text files on a Unix box live elsewhere: /etc, /usr/include, /usr/share, etc.



                      Once upon a time, even shell scripts — which are plain text files — were kept out of bin directories, but this line, too, has blurred. Today, bin directories typically contain any kind of executable file, whether strictly "binary" or not.⁶





                      Footnotes and Digressions:





                      1. The primitive nature of the user management tools prior to SVR4 meant that the HOME=/usr/$NAME scheme was merely documented as a convention, rather than enforced by software tools as a default.



                        You can see this on page 4-8 of the "AT&T Unix System V Release 3.2 System Administrator's Guide: here you see AT&T recommending the old /usr/$NAME scheme in the last major version of Unix before SVR4 came out.



                        It was fairly common in older Unix systems for the system administrators to choose a different scheme that made more sense to them. People being people, that meant a lot of different schemes got invented.



                        One scheme I came across before /home/$NAME became the standard was /u/$NAME.



                        Another system I used in the early 1990s had so many users that they couldn't fit all the home directories onto a single physical volume, so they used a scheme like /u1/$NAME, /u2/$NAME, and so on, as I recall. Which disk your home directory ended up on was simply a matter of which one had space on it at the time your account was created.




                      2. You can boot a macOS box into single-user mode by holding down Cmd-S while it boots. Let go once the screen turns black and you see light gray text appear. It's like running under the Terminal, but it takes over the whole screen because the GUI hasn't started yet.



                        Be careful, you're running as root.



                        Type "exit" at the single-user root prompt to leave single-user mode and continue booting into multi-user GUI mode.




                      3. Unixy OSes that still appear to keep critical single-user mode files out of /usr may not, in fact, do so these days. I once rendered a FreeBSD 9 box unbootable by moving /usr to a ZFS volume. I forgot that the ZFS-on-root features didn't land until FreeBSD 10, creating a Catch 22: the OS needed files in /usr in order to mount /usr!



                        That was bad enough, but if FreeBSD 9 were still keeping its single-user boot stuff out of /usr, I could have fixed it in place. Since it wouldn't boot even to single-user mode with /usr being unmountable, clearly that tradition had been violated somehow. I had to boot from a rescue CD to get that system back up again.



                      4. This is also where we get /usr/share: it segregates files that could be shared even between Unix boxes with different processor types. Typically, text files: man pages, the dictionary, etc.


                      5. "X11R6" referred to the version of the X Window System underpinning Linux GUIs at the time this convention was prevalent. Linux systems generally stopped segregating the GUI software about the time X11R6 was replaced with X.Org.


                      6. The original Unix systems kept their core shell scripts in /etc in order to avoid commingling them with the true binaries in /bin.







                      share|improve this answer
















                      /usr/, I assume is the user of the computer.




                      Close.



                      Unix started out as a multi-user operating system, so it's not "the user," it's "the users," plural.



                      Before AT&T Unix System V Release 4 (SVR4) came out in 1988 with its user management tools defaulting to creating user home directories in /home, the conventional location was /usr.¹ Your $HOME directory might have been /usr/jfw on a System III box.



                      /usr also contained, then as now, /usr/bin, /usr/lib, etc. Experience showed that segregating the home directories was good system management practice, so with the /home policy change in SVR4, it left behind everything we now think of as belonging in /usr.



                      /usr still had a good reason to hold onto the name: what got left behind were files that didn't need to be available until the system was booted up far enough to support normal interactive use. That is to say, what was left behind were the user-focused parts of the OS. This meant that /usr could be on a different physical volume, which was a good thing back in the days of 92 MB hard disk drives the size of washing machines.



                      Early Unix systems were careful to keep the core OS files out of /usr so that you could still boot into single-user mode² even if the /usr volume was unmountable for some reason. The root volume contained sufficient tools to get the /usr volume back online.



                      Several Unix flavors now disregard this old design principle since even small embedded systems have enough room for both the traditional root volume files and all of /usr on a single volume.³ Red Hat Enterprise Linux, Solaris and Cygwin symlink /bin to /usr/bin and /lib to /usr/lib so that there is no longer any difference between these directories.




                      .../local/...obviously stands for the local computer...




                      Yes. It refers to the fact that files under /usr/local are supposed to be particular to that single system. Files that are in any way generic should live elsewhere.



                      This also has roots in the way Unix systems were commonly used decades ago when all this was standardized. Again, hard disks of the time were bulky, really expensive, and stored little by today's standards. To save money and space on disks, a computer lab full of Unix boxes would often share most of /usr over NFS or some other network file sharing protocol, so each box didn't have to have its own redundant copy.⁴ Files specific to a single box would go under /usr/local, which would be a separate volume from /usr.



                      This historical heritage is why it's still the default for most third-party Unix software to install into /usr/local when installed by hand. Most such software will let you install the package somewhere else, but by making a non-choice, you get the safe default, which doesn't interfere with other common install locations with more specific purposes.



                      There are good reasons to make software install somewhere else instead. Apple's macOS team does this when they build, say, bash from the GNU Bash source code. They use / as the installation prefix, overriding the /usr/local default, so that Bash ends up in /bin.



                      Another example is the way older Linux systems segregated their GUI software into /usr/X11R6, to keep it separate from the traditional command line and curses-based software. This was done simply by overriding the default /usr/local prefix with /usr/X11R6.⁵




                      And what is /bin?




                      It's short for "binary," which in this context means "a file that is not plain text." Most such files are executables on a Unix box, so these two terms have become synonymous in some circles. ("Please build me a binary for RHEL 7, Fred.")



                      Text files on a Unix box live elsewhere: /etc, /usr/include, /usr/share, etc.



                      Once upon a time, even shell scripts — which are plain text files — were kept out of bin directories, but this line, too, has blurred. Today, bin directories typically contain any kind of executable file, whether strictly "binary" or not.⁶





                      Footnotes and Digressions:





                      1. The primitive nature of the user management tools prior to SVR4 meant that the HOME=/usr/$NAME scheme was merely documented as a convention, rather than enforced by software tools as a default.



                        You can see this on page 4-8 of the "AT&T Unix System V Release 3.2 System Administrator's Guide: here you see AT&T recommending the old /usr/$NAME scheme in the last major version of Unix before SVR4 came out.



                        It was fairly common in older Unix systems for the system administrators to choose a different scheme that made more sense to them. People being people, that meant a lot of different schemes got invented.



                        One scheme I came across before /home/$NAME became the standard was /u/$NAME.



                        Another system I used in the early 1990s had so many users that they couldn't fit all the home directories onto a single physical volume, so they used a scheme like /u1/$NAME, /u2/$NAME, and so on, as I recall. Which disk your home directory ended up on was simply a matter of which one had space on it at the time your account was created.




                      2. You can boot a macOS box into single-user mode by holding down Cmd-S while it boots. Let go once the screen turns black and you see light gray text appear. It's like running under the Terminal, but it takes over the whole screen because the GUI hasn't started yet.



                        Be careful, you're running as root.



                        Type "exit" at the single-user root prompt to leave single-user mode and continue booting into multi-user GUI mode.




                      3. Unixy OSes that still appear to keep critical single-user mode files out of /usr may not, in fact, do so these days. I once rendered a FreeBSD 9 box unbootable by moving /usr to a ZFS volume. I forgot that the ZFS-on-root features didn't land until FreeBSD 10, creating a Catch 22: the OS needed files in /usr in order to mount /usr!



                        That was bad enough, but if FreeBSD 9 were still keeping its single-user boot stuff out of /usr, I could have fixed it in place. Since it wouldn't boot even to single-user mode with /usr being unmountable, clearly that tradition had been violated somehow. I had to boot from a rescue CD to get that system back up again.



                      4. This is also where we get /usr/share: it segregates files that could be shared even between Unix boxes with different processor types. Typically, text files: man pages, the dictionary, etc.


                      5. "X11R6" referred to the version of the X Window System underpinning Linux GUIs at the time this convention was prevalent. Linux systems generally stopped segregating the GUI software about the time X11R6 was replaced with X.Org.


                      6. The original Unix systems kept their core shell scripts in /etc in order to avoid commingling them with the true binaries in /bin.








                      share|improve this answer














                      share|improve this answer



                      share|improve this answer








                      edited Sep 21 '18 at 16:51

























                      answered Nov 18 '10 at 18:34









                      Warren YoungWarren Young

                      55k11143147




                      55k11143147








                      • 1





                        Loved that picture of washing machine!

                        – asgs
                        Oct 12 '17 at 20:18











                      • @Warren, What are the notable OSes before System III?

                        – Pacerier
                        Nov 1 '17 at 20:59











                      • @Pacerier: UNIX Versions 1 through 7, UNIX/32V, 1BSD through 4BSD not including the dot releases of 4BSD (4.1BSD was roughly contemporaneous with AT&T Unix System III), and PWB Unix. Source. Why do you ask, and what does it have to do with this question?

                        – Warren Young
                        Nov 1 '17 at 21:33











                      • @Warren, Well, they might have affected the defacto "directory naming system" somehow

                        – Pacerier
                        Nov 1 '17 at 21:34













                      • @Pacerier: I'll stand by my claim: there was no "standard" before System V, only conventions and local practices.

                        – Warren Young
                        Nov 1 '17 at 21:35














                      • 1





                        Loved that picture of washing machine!

                        – asgs
                        Oct 12 '17 at 20:18











                      • @Warren, What are the notable OSes before System III?

                        – Pacerier
                        Nov 1 '17 at 20:59











                      • @Pacerier: UNIX Versions 1 through 7, UNIX/32V, 1BSD through 4BSD not including the dot releases of 4BSD (4.1BSD was roughly contemporaneous with AT&T Unix System III), and PWB Unix. Source. Why do you ask, and what does it have to do with this question?

                        – Warren Young
                        Nov 1 '17 at 21:33











                      • @Warren, Well, they might have affected the defacto "directory naming system" somehow

                        – Pacerier
                        Nov 1 '17 at 21:34













                      • @Pacerier: I'll stand by my claim: there was no "standard" before System V, only conventions and local practices.

                        – Warren Young
                        Nov 1 '17 at 21:35








                      1




                      1





                      Loved that picture of washing machine!

                      – asgs
                      Oct 12 '17 at 20:18





                      Loved that picture of washing machine!

                      – asgs
                      Oct 12 '17 at 20:18













                      @Warren, What are the notable OSes before System III?

                      – Pacerier
                      Nov 1 '17 at 20:59





                      @Warren, What are the notable OSes before System III?

                      – Pacerier
                      Nov 1 '17 at 20:59













                      @Pacerier: UNIX Versions 1 through 7, UNIX/32V, 1BSD through 4BSD not including the dot releases of 4BSD (4.1BSD was roughly contemporaneous with AT&T Unix System III), and PWB Unix. Source. Why do you ask, and what does it have to do with this question?

                      – Warren Young
                      Nov 1 '17 at 21:33





                      @Pacerier: UNIX Versions 1 through 7, UNIX/32V, 1BSD through 4BSD not including the dot releases of 4BSD (4.1BSD was roughly contemporaneous with AT&T Unix System III), and PWB Unix. Source. Why do you ask, and what does it have to do with this question?

                      – Warren Young
                      Nov 1 '17 at 21:33













                      @Warren, Well, they might have affected the defacto "directory naming system" somehow

                      – Pacerier
                      Nov 1 '17 at 21:34







                      @Warren, Well, they might have affected the defacto "directory naming system" somehow

                      – Pacerier
                      Nov 1 '17 at 21:34















                      @Pacerier: I'll stand by my claim: there was no "standard" before System V, only conventions and local practices.

                      – Warren Young
                      Nov 1 '17 at 21:35





                      @Pacerier: I'll stand by my claim: there was no "standard" before System V, only conventions and local practices.

                      – Warren Young
                      Nov 1 '17 at 21:35











                      9














                      I would recommend referring to Wikipedia for structure related questions in general, it will cover the basics.



                      To answer your question directly, however:




                      • /usr is, loosely, non-critical system libraries and executables

                      • /usr/local is, again loosely, for non-system libraries and executables


                      This is why you tend to find similar structure between the two; /usr/{,local/}{bin,sbin,lib}. Being new to the shell, that bit with the {}'s is a shell expansion. Try executing



                      ls -ld /usr/{,local/}{bin,sbin,lib}


                      from your local shell to see how it works.






                      share|improve this answer




























                        9














                        I would recommend referring to Wikipedia for structure related questions in general, it will cover the basics.



                        To answer your question directly, however:




                        • /usr is, loosely, non-critical system libraries and executables

                        • /usr/local is, again loosely, for non-system libraries and executables


                        This is why you tend to find similar structure between the two; /usr/{,local/}{bin,sbin,lib}. Being new to the shell, that bit with the {}'s is a shell expansion. Try executing



                        ls -ld /usr/{,local/}{bin,sbin,lib}


                        from your local shell to see how it works.






                        share|improve this answer


























                          9












                          9








                          9







                          I would recommend referring to Wikipedia for structure related questions in general, it will cover the basics.



                          To answer your question directly, however:




                          • /usr is, loosely, non-critical system libraries and executables

                          • /usr/local is, again loosely, for non-system libraries and executables


                          This is why you tend to find similar structure between the two; /usr/{,local/}{bin,sbin,lib}. Being new to the shell, that bit with the {}'s is a shell expansion. Try executing



                          ls -ld /usr/{,local/}{bin,sbin,lib}


                          from your local shell to see how it works.






                          share|improve this answer













                          I would recommend referring to Wikipedia for structure related questions in general, it will cover the basics.



                          To answer your question directly, however:




                          • /usr is, loosely, non-critical system libraries and executables

                          • /usr/local is, again loosely, for non-system libraries and executables


                          This is why you tend to find similar structure between the two; /usr/{,local/}{bin,sbin,lib}. Being new to the shell, that bit with the {}'s is a shell expansion. Try executing



                          ls -ld /usr/{,local/}{bin,sbin,lib}


                          from your local shell to see how it works.







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Nov 18 '10 at 14:11









                          TokTok

                          6,99421810




                          6,99421810























                              8














                              /usr/local/bin shows the UNIX-esque roots of the latest Mac OS (its BSD based under there).




                              • "usr" stands for UNIX System Resources. This is the location that system programs and libraries are stored.

                              • "local" represents resources that were not shipped with the standard distribution and, usually, compiled and maintained on a per site basis.

                              • "bin" represents binary compiled executables.


                              This has morphed since the early implementations of UNIX to Linux and BSD, but the convention has stayed. Now, /usr/bin would be for "main" or core programs and libraries where /usr/local/bin would be for add-on and non-critical programs and libraries.






                              share|improve this answer





















                              • 11





                                I've been using Unix since shortly after the Berlin Wall fell, and I'd never heard the "Unix System Resources" expansion for "usr" until today; it is a backronym. "usr" got its name because it's where the user home directories were originally located. That is, if you had a login on an old System III box, your initial working directory would be /usr/nzwulfin by default. Another common scheme. before the SVR4 /home scheme took over, was /u. One system I used early on had so many users they needed multiple physical disks for user file storage, so they had things like /u/d5/tangent.

                                – Warren Young
                                Nov 18 '10 at 17:54






                              • 3





                                @Warren I hadn't heard it either and poked around Google for a while; it sounds like there are quite a few backronyms

                                – Michael Mrozek
                                Nov 19 '10 at 23:35
















                              8














                              /usr/local/bin shows the UNIX-esque roots of the latest Mac OS (its BSD based under there).




                              • "usr" stands for UNIX System Resources. This is the location that system programs and libraries are stored.

                              • "local" represents resources that were not shipped with the standard distribution and, usually, compiled and maintained on a per site basis.

                              • "bin" represents binary compiled executables.


                              This has morphed since the early implementations of UNIX to Linux and BSD, but the convention has stayed. Now, /usr/bin would be for "main" or core programs and libraries where /usr/local/bin would be for add-on and non-critical programs and libraries.






                              share|improve this answer





















                              • 11





                                I've been using Unix since shortly after the Berlin Wall fell, and I'd never heard the "Unix System Resources" expansion for "usr" until today; it is a backronym. "usr" got its name because it's where the user home directories were originally located. That is, if you had a login on an old System III box, your initial working directory would be /usr/nzwulfin by default. Another common scheme. before the SVR4 /home scheme took over, was /u. One system I used early on had so many users they needed multiple physical disks for user file storage, so they had things like /u/d5/tangent.

                                – Warren Young
                                Nov 18 '10 at 17:54






                              • 3





                                @Warren I hadn't heard it either and poked around Google for a while; it sounds like there are quite a few backronyms

                                – Michael Mrozek
                                Nov 19 '10 at 23:35














                              8












                              8








                              8







                              /usr/local/bin shows the UNIX-esque roots of the latest Mac OS (its BSD based under there).




                              • "usr" stands for UNIX System Resources. This is the location that system programs and libraries are stored.

                              • "local" represents resources that were not shipped with the standard distribution and, usually, compiled and maintained on a per site basis.

                              • "bin" represents binary compiled executables.


                              This has morphed since the early implementations of UNIX to Linux and BSD, but the convention has stayed. Now, /usr/bin would be for "main" or core programs and libraries where /usr/local/bin would be for add-on and non-critical programs and libraries.






                              share|improve this answer















                              /usr/local/bin shows the UNIX-esque roots of the latest Mac OS (its BSD based under there).




                              • "usr" stands for UNIX System Resources. This is the location that system programs and libraries are stored.

                              • "local" represents resources that were not shipped with the standard distribution and, usually, compiled and maintained on a per site basis.

                              • "bin" represents binary compiled executables.


                              This has morphed since the early implementations of UNIX to Linux and BSD, but the convention has stayed. Now, /usr/bin would be for "main" or core programs and libraries where /usr/local/bin would be for add-on and non-critical programs and libraries.







                              share|improve this answer














                              share|improve this answer



                              share|improve this answer








                              edited Nov 19 '14 at 19:04









                              slm

                              250k66523683




                              250k66523683










                              answered Nov 18 '10 at 14:12









                              nzwulfinnzwulfin

                              67743




                              67743








                              • 11





                                I've been using Unix since shortly after the Berlin Wall fell, and I'd never heard the "Unix System Resources" expansion for "usr" until today; it is a backronym. "usr" got its name because it's where the user home directories were originally located. That is, if you had a login on an old System III box, your initial working directory would be /usr/nzwulfin by default. Another common scheme. before the SVR4 /home scheme took over, was /u. One system I used early on had so many users they needed multiple physical disks for user file storage, so they had things like /u/d5/tangent.

                                – Warren Young
                                Nov 18 '10 at 17:54






                              • 3





                                @Warren I hadn't heard it either and poked around Google for a while; it sounds like there are quite a few backronyms

                                – Michael Mrozek
                                Nov 19 '10 at 23:35














                              • 11





                                I've been using Unix since shortly after the Berlin Wall fell, and I'd never heard the "Unix System Resources" expansion for "usr" until today; it is a backronym. "usr" got its name because it's where the user home directories were originally located. That is, if you had a login on an old System III box, your initial working directory would be /usr/nzwulfin by default. Another common scheme. before the SVR4 /home scheme took over, was /u. One system I used early on had so many users they needed multiple physical disks for user file storage, so they had things like /u/d5/tangent.

                                – Warren Young
                                Nov 18 '10 at 17:54






                              • 3





                                @Warren I hadn't heard it either and poked around Google for a while; it sounds like there are quite a few backronyms

                                – Michael Mrozek
                                Nov 19 '10 at 23:35








                              11




                              11





                              I've been using Unix since shortly after the Berlin Wall fell, and I'd never heard the "Unix System Resources" expansion for "usr" until today; it is a backronym. "usr" got its name because it's where the user home directories were originally located. That is, if you had a login on an old System III box, your initial working directory would be /usr/nzwulfin by default. Another common scheme. before the SVR4 /home scheme took over, was /u. One system I used early on had so many users they needed multiple physical disks for user file storage, so they had things like /u/d5/tangent.

                              – Warren Young
                              Nov 18 '10 at 17:54





                              I've been using Unix since shortly after the Berlin Wall fell, and I'd never heard the "Unix System Resources" expansion for "usr" until today; it is a backronym. "usr" got its name because it's where the user home directories were originally located. That is, if you had a login on an old System III box, your initial working directory would be /usr/nzwulfin by default. Another common scheme. before the SVR4 /home scheme took over, was /u. One system I used early on had so many users they needed multiple physical disks for user file storage, so they had things like /u/d5/tangent.

                              – Warren Young
                              Nov 18 '10 at 17:54




                              3




                              3





                              @Warren I hadn't heard it either and poked around Google for a while; it sounds like there are quite a few backronyms

                              – Michael Mrozek
                              Nov 19 '10 at 23:35





                              @Warren I hadn't heard it either and poked around Google for a while; it sounds like there are quite a few backronyms

                              – Michael Mrozek
                              Nov 19 '10 at 23:35











                              4














                              /usr/local/bin is the most popular default location for executable files, especially open source ones.



                              This is however arguably a poor choice as, on Unix systems, /usr has been standardized in the early nineties to contain a hierarchy of files that belong to the operating system and thus can be shared by multiple systems using that OS.



                              As these files are static, the /usr file system can be mounted read-only. /usr/local is defeating this standard as it is by design local thus non shared, so needs to be read-write to allow local compilation and isn't part of the operating system. Too bad something like /opt/local wasn't chosen instead ...






                              share|improve this answer






























                                4














                                /usr/local/bin is the most popular default location for executable files, especially open source ones.



                                This is however arguably a poor choice as, on Unix systems, /usr has been standardized in the early nineties to contain a hierarchy of files that belong to the operating system and thus can be shared by multiple systems using that OS.



                                As these files are static, the /usr file system can be mounted read-only. /usr/local is defeating this standard as it is by design local thus non shared, so needs to be read-write to allow local compilation and isn't part of the operating system. Too bad something like /opt/local wasn't chosen instead ...






                                share|improve this answer




























                                  4












                                  4








                                  4







                                  /usr/local/bin is the most popular default location for executable files, especially open source ones.



                                  This is however arguably a poor choice as, on Unix systems, /usr has been standardized in the early nineties to contain a hierarchy of files that belong to the operating system and thus can be shared by multiple systems using that OS.



                                  As these files are static, the /usr file system can be mounted read-only. /usr/local is defeating this standard as it is by design local thus non shared, so needs to be read-write to allow local compilation and isn't part of the operating system. Too bad something like /opt/local wasn't chosen instead ...






                                  share|improve this answer















                                  /usr/local/bin is the most popular default location for executable files, especially open source ones.



                                  This is however arguably a poor choice as, on Unix systems, /usr has been standardized in the early nineties to contain a hierarchy of files that belong to the operating system and thus can be shared by multiple systems using that OS.



                                  As these files are static, the /usr file system can be mounted read-only. /usr/local is defeating this standard as it is by design local thus non shared, so needs to be read-write to allow local compilation and isn't part of the operating system. Too bad something like /opt/local wasn't chosen instead ...







                                  share|improve this answer














                                  share|improve this answer



                                  share|improve this answer








                                  edited Nov 19 '14 at 19:07









                                  slm

                                  250k66523683




                                  250k66523683










                                  answered Nov 18 '10 at 22:39









                                  jlliagrejlliagre

                                  46.9k783133




                                  46.9k783133























                                      1














                                      On a Mac, while you can only write to /usr as root so Terminal, there is the way to go there in Finder. Use the "Go To Folder..."command under the "Go" menu.






                                      share|improve this answer




























                                        1














                                        On a Mac, while you can only write to /usr as root so Terminal, there is the way to go there in Finder. Use the "Go To Folder..."command under the "Go" menu.






                                        share|improve this answer


























                                          1












                                          1








                                          1







                                          On a Mac, while you can only write to /usr as root so Terminal, there is the way to go there in Finder. Use the "Go To Folder..."command under the "Go" menu.






                                          share|improve this answer













                                          On a Mac, while you can only write to /usr as root so Terminal, there is the way to go there in Finder. Use the "Go To Folder..."command under the "Go" menu.







                                          share|improve this answer












                                          share|improve this answer



                                          share|improve this answer










                                          answered Nov 30 '13 at 4:23









                                          voidstatevoidstate

                                          1112




                                          1112























                                              1














                                              I recommend you use /usr/local for commercial programs you might install such as Mathematica. Place it in its own partition when you set up. When you upgrade your OS, this partition won't be disturbed and you won't have to re-install its contents. So use it for stuff you want to keep between OS upgrades.



                                              Separately, make sure you give /home its own partition for this reason too.






                                              share|improve this answer






























                                                1














                                                I recommend you use /usr/local for commercial programs you might install such as Mathematica. Place it in its own partition when you set up. When you upgrade your OS, this partition won't be disturbed and you won't have to re-install its contents. So use it for stuff you want to keep between OS upgrades.



                                                Separately, make sure you give /home its own partition for this reason too.






                                                share|improve this answer




























                                                  1












                                                  1








                                                  1







                                                  I recommend you use /usr/local for commercial programs you might install such as Mathematica. Place it in its own partition when you set up. When you upgrade your OS, this partition won't be disturbed and you won't have to re-install its contents. So use it for stuff you want to keep between OS upgrades.



                                                  Separately, make sure you give /home its own partition for this reason too.






                                                  share|improve this answer















                                                  I recommend you use /usr/local for commercial programs you might install such as Mathematica. Place it in its own partition when you set up. When you upgrade your OS, this partition won't be disturbed and you won't have to re-install its contents. So use it for stuff you want to keep between OS upgrades.



                                                  Separately, make sure you give /home its own partition for this reason too.







                                                  share|improve this answer














                                                  share|improve this answer



                                                  share|improve this answer








                                                  edited Nov 19 '14 at 19:03









                                                  slm

                                                  250k66523683




                                                  250k66523683










                                                  answered Jul 4 '11 at 0:46









                                                  ncmathsadistncmathsadist

                                                  1293




                                                  1293























                                                      0














                                                      This answer might be helpful as well.



                                                      /usr/local



                                                      The original idea behind /usr/local was to have a separate ('local') '/usr' directory on every machine besides /usr, which might be just mounted read-only from somewhere else. It copies the structure of /usr.



                                                      These days, /usr/local is widely regarded as a good place in which to keep self-compiled or third-party programs. The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated.



                                                      It may be used for programs and data that are shared among a group of hosts, but not found in /usr. Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr.






                                                      share|improve this answer






























                                                        0














                                                        This answer might be helpful as well.



                                                        /usr/local



                                                        The original idea behind /usr/local was to have a separate ('local') '/usr' directory on every machine besides /usr, which might be just mounted read-only from somewhere else. It copies the structure of /usr.



                                                        These days, /usr/local is widely regarded as a good place in which to keep self-compiled or third-party programs. The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated.



                                                        It may be used for programs and data that are shared among a group of hosts, but not found in /usr. Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr.






                                                        share|improve this answer




























                                                          0












                                                          0








                                                          0







                                                          This answer might be helpful as well.



                                                          /usr/local



                                                          The original idea behind /usr/local was to have a separate ('local') '/usr' directory on every machine besides /usr, which might be just mounted read-only from somewhere else. It copies the structure of /usr.



                                                          These days, /usr/local is widely regarded as a good place in which to keep self-compiled or third-party programs. The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated.



                                                          It may be used for programs and data that are shared among a group of hosts, but not found in /usr. Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr.






                                                          share|improve this answer















                                                          This answer might be helpful as well.



                                                          /usr/local



                                                          The original idea behind /usr/local was to have a separate ('local') '/usr' directory on every machine besides /usr, which might be just mounted read-only from somewhere else. It copies the structure of /usr.



                                                          These days, /usr/local is widely regarded as a good place in which to keep self-compiled or third-party programs. The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated.



                                                          It may be used for programs and data that are shared among a group of hosts, but not found in /usr. Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr.







                                                          share|improve this answer














                                                          share|improve this answer



                                                          share|improve this answer








                                                          edited Nov 19 '14 at 19:02









                                                          slm

                                                          250k66523683




                                                          250k66523683










                                                          answered Oct 21 '14 at 3:59









                                                          Vishwanath gowda kVishwanath gowda k

                                                          34039




                                                          34039























                                                              0














                                                              usr==user?
                                                              I think usr stands for Unix System Resource





                                                              share








                                                              New contributor




                                                              Aliar is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                              Check out our Code of Conduct.

























                                                                0














                                                                usr==user?
                                                                I think usr stands for Unix System Resource





                                                                share








                                                                New contributor




                                                                Aliar is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                                Check out our Code of Conduct.























                                                                  0












                                                                  0








                                                                  0







                                                                  usr==user?
                                                                  I think usr stands for Unix System Resource





                                                                  share








                                                                  New contributor




                                                                  Aliar is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                                  Check out our Code of Conduct.










                                                                  usr==user?
                                                                  I think usr stands for Unix System Resource






                                                                  share








                                                                  New contributor




                                                                  Aliar is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                                  Check out our Code of Conduct.








                                                                  share


                                                                  share






                                                                  New contributor




                                                                  Aliar is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                                  Check out our Code of Conduct.









                                                                  answered 3 mins ago









                                                                  AliarAliar

                                                                  1




                                                                  1




                                                                  New contributor




                                                                  Aliar is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                                  Check out our Code of Conduct.





                                                                  New contributor





                                                                  Aliar is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                                  Check out our Code of Conduct.






                                                                  Aliar is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
                                                                  Check out our Code of Conduct.






























                                                                      draft saved

                                                                      draft discarded




















































                                                                      Thanks for contributing an answer to Unix & Linux Stack Exchange!


                                                                      • Please be sure to answer the question. Provide details and share your research!

                                                                      But avoid



                                                                      • Asking for help, clarification, or responding to other answers.

                                                                      • Making statements based on opinion; back them up with references or personal experience.


                                                                      To learn more, see our tips on writing great answers.




                                                                      draft saved


                                                                      draft discarded














                                                                      StackExchange.ready(
                                                                      function () {
                                                                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f4186%2fwhat-is-usr-local-bin%23new-answer', 'question_page');
                                                                      }
                                                                      );

                                                                      Post as a guest















                                                                      Required, but never shown





















































                                                                      Required, but never shown














                                                                      Required, but never shown












                                                                      Required, but never shown







                                                                      Required, but never shown

































                                                                      Required, but never shown














                                                                      Required, but never shown












                                                                      Required, but never shown







                                                                      Required, but never shown







                                                                      Popular posts from this blog

                                                                      Loup dans la culture

                                                                      How to solve the problem of ntp “Unable to contact time server” from KDE?

                                                                      ASUS Zenbook UX433/UX333 — Configure Touchpad-embedded numpad on Linux