Where should a local executable be placed?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
44
down vote

favorite
33












I have an executable for the perforce version control client (p4). I can't place it in /opt/local because I don't have root privileges. Is there a standard location where it needs to be placed under $HOME?



Does the File System Hierarchy have a convention that says that local executables/binaries need to be placed in $HOME/bin?



I couldn't find such a convention mentioned on the Wikipedia article for the FHS.



Also, if there indeed is a convention, would I have to explicitly include the path to the $HOME/bin directory or whatever the location of the bin directory is?







share|improve this question

























    up vote
    44
    down vote

    favorite
    33












    I have an executable for the perforce version control client (p4). I can't place it in /opt/local because I don't have root privileges. Is there a standard location where it needs to be placed under $HOME?



    Does the File System Hierarchy have a convention that says that local executables/binaries need to be placed in $HOME/bin?



    I couldn't find such a convention mentioned on the Wikipedia article for the FHS.



    Also, if there indeed is a convention, would I have to explicitly include the path to the $HOME/bin directory or whatever the location of the bin directory is?







    share|improve this question























      up vote
      44
      down vote

      favorite
      33









      up vote
      44
      down vote

      favorite
      33






      33





      I have an executable for the perforce version control client (p4). I can't place it in /opt/local because I don't have root privileges. Is there a standard location where it needs to be placed under $HOME?



      Does the File System Hierarchy have a convention that says that local executables/binaries need to be placed in $HOME/bin?



      I couldn't find such a convention mentioned on the Wikipedia article for the FHS.



      Also, if there indeed is a convention, would I have to explicitly include the path to the $HOME/bin directory or whatever the location of the bin directory is?







      share|improve this question













      I have an executable for the perforce version control client (p4). I can't place it in /opt/local because I don't have root privileges. Is there a standard location where it needs to be placed under $HOME?



      Does the File System Hierarchy have a convention that says that local executables/binaries need to be placed in $HOME/bin?



      I couldn't find such a convention mentioned on the Wikipedia article for the FHS.



      Also, if there indeed is a convention, would I have to explicitly include the path to the $HOME/bin directory or whatever the location of the bin directory is?









      share|improve this question












      share|improve this question




      share|improve this question








      edited Apr 19 '12 at 22:36









      Gilles

      503k1179951521




      503k1179951521









      asked Apr 19 '12 at 14:16









      user640378

      4482712




      4482712




















          2 Answers
          2






          active

          oldest

          votes

















          up vote
          48
          down vote



          accepted










          In general, if a non-system installed and maintained binary needs to be accessible system-wide to multiple users, it should be placed by an administrator into /usr/local/bin. There is a complete hierarchy under /usr/local that is generally used for locally compiled and installed software packages.



          If you are the only user of a binary, installing into $HOME/bin is the appropriate location since you can install it yourself and you will be the only consumer. If you compile a software package from source, it's also appropriate to create a partial or full local hierarchy in your $HOME directory. The full local hierarchy would look like this.




          • $HOME/bin Local binaries


          • $HOME/etc Host-specific system configuration for local binaries


          • $HOME/games Local game binaries


          • $HOME/include Local C header files


          • $HOME/lib Local libraries


          • $HOME/lib64 Local 64-bit libraries


          • $HOME/man Local online manuals


          • $HOME/sbin Local system binaries


          • $HOME/share Local architecture-independent hierarchy


          • $HOME/src Local source code

          When running configure, you should define your local hierarchy for installation by specifying $HOME as the prefix for the installation defaults.



          ./configure --prefix=$HOME



          Now when make && make install are run, the compiled binaries, packages, man pages, and libraries will be installed into your $HOME local hierarchy. If you have not manually created a $HOME local hierarchy, make install will create the directories needed by the software package.



          Once installed in $HOME/bin, you can either add $HOME/bin to your $PATH or call the binary using the absolute $PATH. Some distributions will include $HOME/bin into your $PATH by default. You can test this by either echo $PATH and seeing if $HOME/bin is there, or put the binary in $HOME/bin and executing which binaryname. If it comes back with $HOME/bin/binaryname, then it is in your $PATH by default.






          share|improve this answer



















          • 5




            as long as $HOME is not on a noexec mounted filesystem. /tmp/ is usually mounted noexec too.
            – ewanm89
            Apr 19 '12 at 17:24






          • 3




            This is correct, its part of the Filesystem Hierarchy Standard (FHS). pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY
            – Patrick
            Apr 19 '12 at 22:58







          • 23




            I would not recommend using $HOME. This inundates your home directory with numerous directories that you are not interested in at all. Who wants to have man, lib, etc. in ones home dir? I would rather create the hierarchy below $HOME/bin or $HOME/local. That adds only one subdirectory to your home dir, instead of ten. The PATH can easily be adapted to include $HOME/bin/bin or $HOME/local/bin.
            – Marco
            May 3 '12 at 0:43






          • 15




            One option is to use $HOME/.local/bin,lib,etc., as used by e.g. the XDG basedir spec (standards.freedesktop.org/basedir-spec/basedir-spec-latest.html ) and python (python.org/dev/peps/pep-0370 )
            – janneb
            May 28 '13 at 19:20






          • 4




            @janneb The XDG Base Directory Specification you refer to mentions only $HOME/.local/share (Version 0.7, 24th November 2010).
            – Piotr Dobrogost
            Nov 3 '15 at 22:06


















          up vote
          19
          down vote













          As uther mentioned, /usr/local is intended as a prefix for, essentially, software installed by the system administrator, while /usr should be used for software installed from the distribution's packages.



          The idea behind this is to avoid clashes with distributed software (such as rpm and deb packages) and give the admin full reign over the "local" prefix.



          This means that an admin can install custom compiled software while still using a distro like debian.




          From the FHS



          Software placed in / or /usr may be overwritten by system upgrades (though we recommend that distributions do not overwrite data in /etc under these circumstances). For this reason, local software must not be placed outside of /usr/local without good reason.




          When installing user-specific software, uther suggests using $HOME as the prefix since this ensures you have write permissions. Personally, I feel using $HOME/.local to be a more elegant solution, since it avoides cluttering your (hopefully) nice and tidy home directory!



          $HOME/.local/share is already used in the freedesktop.org XDG Base Directory specification, so it doesn't take much to envision adding a $HOME/.local/bin to your $PATH and making a $HOME/.local/lib, etc, while you're at it.



          If you don't really want your prefix to be a hidden directory, you could easily create a symbolic link to it as well, e.g:



          ln -s .local ~/local



          Sidenote



          It is worth noting that .config (not .local/etc) is the default value for $XDG_CONFIG_HOME used for user specific config files. I should also point out that, unfortunately, a large portion of software ignores the XDG and creates config files wherever they like (usually in the root of $HOME). Also note that $XDG_CONFIG_HOME may be unset if the default $HOME/.config is desired.



          Oddly, there is no directory reserved for a distribution's default config files, so there is no way to know if a file in /etc was supplied by the distro or edited by the system administrator.






          share|improve this answer



















          • 1




            I can't find any mention of .local in the FHS
            – Daniel Serodio
            Oct 25 '17 at 17:14










          • @DanielSerodio It's in the XDG directory specification, a newer standard that it gaining prominence. See unix.stackexchange.com/questions/316765/… and superuser.com/questions/1170793/…
            – ivan_pozdeev
            Nov 7 '17 at 11:47










          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',
          convertImagesToLinks: false,
          noModals: false,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          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%2f36871%2fwhere-should-a-local-executable-be-placed%23new-answer', 'question_page');

          );

          Post as a guest






























          2 Answers
          2






          active

          oldest

          votes








          2 Answers
          2






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          48
          down vote



          accepted










          In general, if a non-system installed and maintained binary needs to be accessible system-wide to multiple users, it should be placed by an administrator into /usr/local/bin. There is a complete hierarchy under /usr/local that is generally used for locally compiled and installed software packages.



          If you are the only user of a binary, installing into $HOME/bin is the appropriate location since you can install it yourself and you will be the only consumer. If you compile a software package from source, it's also appropriate to create a partial or full local hierarchy in your $HOME directory. The full local hierarchy would look like this.




          • $HOME/bin Local binaries


          • $HOME/etc Host-specific system configuration for local binaries


          • $HOME/games Local game binaries


          • $HOME/include Local C header files


          • $HOME/lib Local libraries


          • $HOME/lib64 Local 64-bit libraries


          • $HOME/man Local online manuals


          • $HOME/sbin Local system binaries


          • $HOME/share Local architecture-independent hierarchy


          • $HOME/src Local source code

          When running configure, you should define your local hierarchy for installation by specifying $HOME as the prefix for the installation defaults.



          ./configure --prefix=$HOME



          Now when make && make install are run, the compiled binaries, packages, man pages, and libraries will be installed into your $HOME local hierarchy. If you have not manually created a $HOME local hierarchy, make install will create the directories needed by the software package.



          Once installed in $HOME/bin, you can either add $HOME/bin to your $PATH or call the binary using the absolute $PATH. Some distributions will include $HOME/bin into your $PATH by default. You can test this by either echo $PATH and seeing if $HOME/bin is there, or put the binary in $HOME/bin and executing which binaryname. If it comes back with $HOME/bin/binaryname, then it is in your $PATH by default.






          share|improve this answer



















          • 5




            as long as $HOME is not on a noexec mounted filesystem. /tmp/ is usually mounted noexec too.
            – ewanm89
            Apr 19 '12 at 17:24






          • 3




            This is correct, its part of the Filesystem Hierarchy Standard (FHS). pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY
            – Patrick
            Apr 19 '12 at 22:58







          • 23




            I would not recommend using $HOME. This inundates your home directory with numerous directories that you are not interested in at all. Who wants to have man, lib, etc. in ones home dir? I would rather create the hierarchy below $HOME/bin or $HOME/local. That adds only one subdirectory to your home dir, instead of ten. The PATH can easily be adapted to include $HOME/bin/bin or $HOME/local/bin.
            – Marco
            May 3 '12 at 0:43






          • 15




            One option is to use $HOME/.local/bin,lib,etc., as used by e.g. the XDG basedir spec (standards.freedesktop.org/basedir-spec/basedir-spec-latest.html ) and python (python.org/dev/peps/pep-0370 )
            – janneb
            May 28 '13 at 19:20






          • 4




            @janneb The XDG Base Directory Specification you refer to mentions only $HOME/.local/share (Version 0.7, 24th November 2010).
            – Piotr Dobrogost
            Nov 3 '15 at 22:06















          up vote
          48
          down vote



          accepted










          In general, if a non-system installed and maintained binary needs to be accessible system-wide to multiple users, it should be placed by an administrator into /usr/local/bin. There is a complete hierarchy under /usr/local that is generally used for locally compiled and installed software packages.



          If you are the only user of a binary, installing into $HOME/bin is the appropriate location since you can install it yourself and you will be the only consumer. If you compile a software package from source, it's also appropriate to create a partial or full local hierarchy in your $HOME directory. The full local hierarchy would look like this.




          • $HOME/bin Local binaries


          • $HOME/etc Host-specific system configuration for local binaries


          • $HOME/games Local game binaries


          • $HOME/include Local C header files


          • $HOME/lib Local libraries


          • $HOME/lib64 Local 64-bit libraries


          • $HOME/man Local online manuals


          • $HOME/sbin Local system binaries


          • $HOME/share Local architecture-independent hierarchy


          • $HOME/src Local source code

          When running configure, you should define your local hierarchy for installation by specifying $HOME as the prefix for the installation defaults.



          ./configure --prefix=$HOME



          Now when make && make install are run, the compiled binaries, packages, man pages, and libraries will be installed into your $HOME local hierarchy. If you have not manually created a $HOME local hierarchy, make install will create the directories needed by the software package.



          Once installed in $HOME/bin, you can either add $HOME/bin to your $PATH or call the binary using the absolute $PATH. Some distributions will include $HOME/bin into your $PATH by default. You can test this by either echo $PATH and seeing if $HOME/bin is there, or put the binary in $HOME/bin and executing which binaryname. If it comes back with $HOME/bin/binaryname, then it is in your $PATH by default.






          share|improve this answer



















          • 5




            as long as $HOME is not on a noexec mounted filesystem. /tmp/ is usually mounted noexec too.
            – ewanm89
            Apr 19 '12 at 17:24






          • 3




            This is correct, its part of the Filesystem Hierarchy Standard (FHS). pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY
            – Patrick
            Apr 19 '12 at 22:58







          • 23




            I would not recommend using $HOME. This inundates your home directory with numerous directories that you are not interested in at all. Who wants to have man, lib, etc. in ones home dir? I would rather create the hierarchy below $HOME/bin or $HOME/local. That adds only one subdirectory to your home dir, instead of ten. The PATH can easily be adapted to include $HOME/bin/bin or $HOME/local/bin.
            – Marco
            May 3 '12 at 0:43






          • 15




            One option is to use $HOME/.local/bin,lib,etc., as used by e.g. the XDG basedir spec (standards.freedesktop.org/basedir-spec/basedir-spec-latest.html ) and python (python.org/dev/peps/pep-0370 )
            – janneb
            May 28 '13 at 19:20






          • 4




            @janneb The XDG Base Directory Specification you refer to mentions only $HOME/.local/share (Version 0.7, 24th November 2010).
            – Piotr Dobrogost
            Nov 3 '15 at 22:06













          up vote
          48
          down vote



          accepted







          up vote
          48
          down vote



          accepted






          In general, if a non-system installed and maintained binary needs to be accessible system-wide to multiple users, it should be placed by an administrator into /usr/local/bin. There is a complete hierarchy under /usr/local that is generally used for locally compiled and installed software packages.



          If you are the only user of a binary, installing into $HOME/bin is the appropriate location since you can install it yourself and you will be the only consumer. If you compile a software package from source, it's also appropriate to create a partial or full local hierarchy in your $HOME directory. The full local hierarchy would look like this.




          • $HOME/bin Local binaries


          • $HOME/etc Host-specific system configuration for local binaries


          • $HOME/games Local game binaries


          • $HOME/include Local C header files


          • $HOME/lib Local libraries


          • $HOME/lib64 Local 64-bit libraries


          • $HOME/man Local online manuals


          • $HOME/sbin Local system binaries


          • $HOME/share Local architecture-independent hierarchy


          • $HOME/src Local source code

          When running configure, you should define your local hierarchy for installation by specifying $HOME as the prefix for the installation defaults.



          ./configure --prefix=$HOME



          Now when make && make install are run, the compiled binaries, packages, man pages, and libraries will be installed into your $HOME local hierarchy. If you have not manually created a $HOME local hierarchy, make install will create the directories needed by the software package.



          Once installed in $HOME/bin, you can either add $HOME/bin to your $PATH or call the binary using the absolute $PATH. Some distributions will include $HOME/bin into your $PATH by default. You can test this by either echo $PATH and seeing if $HOME/bin is there, or put the binary in $HOME/bin and executing which binaryname. If it comes back with $HOME/bin/binaryname, then it is in your $PATH by default.






          share|improve this answer















          In general, if a non-system installed and maintained binary needs to be accessible system-wide to multiple users, it should be placed by an administrator into /usr/local/bin. There is a complete hierarchy under /usr/local that is generally used for locally compiled and installed software packages.



          If you are the only user of a binary, installing into $HOME/bin is the appropriate location since you can install it yourself and you will be the only consumer. If you compile a software package from source, it's also appropriate to create a partial or full local hierarchy in your $HOME directory. The full local hierarchy would look like this.




          • $HOME/bin Local binaries


          • $HOME/etc Host-specific system configuration for local binaries


          • $HOME/games Local game binaries


          • $HOME/include Local C header files


          • $HOME/lib Local libraries


          • $HOME/lib64 Local 64-bit libraries


          • $HOME/man Local online manuals


          • $HOME/sbin Local system binaries


          • $HOME/share Local architecture-independent hierarchy


          • $HOME/src Local source code

          When running configure, you should define your local hierarchy for installation by specifying $HOME as the prefix for the installation defaults.



          ./configure --prefix=$HOME



          Now when make && make install are run, the compiled binaries, packages, man pages, and libraries will be installed into your $HOME local hierarchy. If you have not manually created a $HOME local hierarchy, make install will create the directories needed by the software package.



          Once installed in $HOME/bin, you can either add $HOME/bin to your $PATH or call the binary using the absolute $PATH. Some distributions will include $HOME/bin into your $PATH by default. You can test this by either echo $PATH and seeing if $HOME/bin is there, or put the binary in $HOME/bin and executing which binaryname. If it comes back with $HOME/bin/binaryname, then it is in your $PATH by default.







          share|improve this answer















          share|improve this answer



          share|improve this answer








          edited May 2 '12 at 12:22


























          answered Apr 19 '12 at 14:27









          George M

          8,69623247




          8,69623247







          • 5




            as long as $HOME is not on a noexec mounted filesystem. /tmp/ is usually mounted noexec too.
            – ewanm89
            Apr 19 '12 at 17:24






          • 3




            This is correct, its part of the Filesystem Hierarchy Standard (FHS). pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY
            – Patrick
            Apr 19 '12 at 22:58







          • 23




            I would not recommend using $HOME. This inundates your home directory with numerous directories that you are not interested in at all. Who wants to have man, lib, etc. in ones home dir? I would rather create the hierarchy below $HOME/bin or $HOME/local. That adds only one subdirectory to your home dir, instead of ten. The PATH can easily be adapted to include $HOME/bin/bin or $HOME/local/bin.
            – Marco
            May 3 '12 at 0:43






          • 15




            One option is to use $HOME/.local/bin,lib,etc., as used by e.g. the XDG basedir spec (standards.freedesktop.org/basedir-spec/basedir-spec-latest.html ) and python (python.org/dev/peps/pep-0370 )
            – janneb
            May 28 '13 at 19:20






          • 4




            @janneb The XDG Base Directory Specification you refer to mentions only $HOME/.local/share (Version 0.7, 24th November 2010).
            – Piotr Dobrogost
            Nov 3 '15 at 22:06













          • 5




            as long as $HOME is not on a noexec mounted filesystem. /tmp/ is usually mounted noexec too.
            – ewanm89
            Apr 19 '12 at 17:24






          • 3




            This is correct, its part of the Filesystem Hierarchy Standard (FHS). pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY
            – Patrick
            Apr 19 '12 at 22:58







          • 23




            I would not recommend using $HOME. This inundates your home directory with numerous directories that you are not interested in at all. Who wants to have man, lib, etc. in ones home dir? I would rather create the hierarchy below $HOME/bin or $HOME/local. That adds only one subdirectory to your home dir, instead of ten. The PATH can easily be adapted to include $HOME/bin/bin or $HOME/local/bin.
            – Marco
            May 3 '12 at 0:43






          • 15




            One option is to use $HOME/.local/bin,lib,etc., as used by e.g. the XDG basedir spec (standards.freedesktop.org/basedir-spec/basedir-spec-latest.html ) and python (python.org/dev/peps/pep-0370 )
            – janneb
            May 28 '13 at 19:20






          • 4




            @janneb The XDG Base Directory Specification you refer to mentions only $HOME/.local/share (Version 0.7, 24th November 2010).
            – Piotr Dobrogost
            Nov 3 '15 at 22:06








          5




          5




          as long as $HOME is not on a noexec mounted filesystem. /tmp/ is usually mounted noexec too.
          – ewanm89
          Apr 19 '12 at 17:24




          as long as $HOME is not on a noexec mounted filesystem. /tmp/ is usually mounted noexec too.
          – ewanm89
          Apr 19 '12 at 17:24




          3




          3




          This is correct, its part of the Filesystem Hierarchy Standard (FHS). pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY
          – Patrick
          Apr 19 '12 at 22:58





          This is correct, its part of the Filesystem Hierarchy Standard (FHS). pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY
          – Patrick
          Apr 19 '12 at 22:58





          23




          23




          I would not recommend using $HOME. This inundates your home directory with numerous directories that you are not interested in at all. Who wants to have man, lib, etc. in ones home dir? I would rather create the hierarchy below $HOME/bin or $HOME/local. That adds only one subdirectory to your home dir, instead of ten. The PATH can easily be adapted to include $HOME/bin/bin or $HOME/local/bin.
          – Marco
          May 3 '12 at 0:43




          I would not recommend using $HOME. This inundates your home directory with numerous directories that you are not interested in at all. Who wants to have man, lib, etc. in ones home dir? I would rather create the hierarchy below $HOME/bin or $HOME/local. That adds only one subdirectory to your home dir, instead of ten. The PATH can easily be adapted to include $HOME/bin/bin or $HOME/local/bin.
          – Marco
          May 3 '12 at 0:43




          15




          15




          One option is to use $HOME/.local/bin,lib,etc., as used by e.g. the XDG basedir spec (standards.freedesktop.org/basedir-spec/basedir-spec-latest.html ) and python (python.org/dev/peps/pep-0370 )
          – janneb
          May 28 '13 at 19:20




          One option is to use $HOME/.local/bin,lib,etc., as used by e.g. the XDG basedir spec (standards.freedesktop.org/basedir-spec/basedir-spec-latest.html ) and python (python.org/dev/peps/pep-0370 )
          – janneb
          May 28 '13 at 19:20




          4




          4




          @janneb The XDG Base Directory Specification you refer to mentions only $HOME/.local/share (Version 0.7, 24th November 2010).
          – Piotr Dobrogost
          Nov 3 '15 at 22:06





          @janneb The XDG Base Directory Specification you refer to mentions only $HOME/.local/share (Version 0.7, 24th November 2010).
          – Piotr Dobrogost
          Nov 3 '15 at 22:06













          up vote
          19
          down vote













          As uther mentioned, /usr/local is intended as a prefix for, essentially, software installed by the system administrator, while /usr should be used for software installed from the distribution's packages.



          The idea behind this is to avoid clashes with distributed software (such as rpm and deb packages) and give the admin full reign over the "local" prefix.



          This means that an admin can install custom compiled software while still using a distro like debian.




          From the FHS



          Software placed in / or /usr may be overwritten by system upgrades (though we recommend that distributions do not overwrite data in /etc under these circumstances). For this reason, local software must not be placed outside of /usr/local without good reason.




          When installing user-specific software, uther suggests using $HOME as the prefix since this ensures you have write permissions. Personally, I feel using $HOME/.local to be a more elegant solution, since it avoides cluttering your (hopefully) nice and tidy home directory!



          $HOME/.local/share is already used in the freedesktop.org XDG Base Directory specification, so it doesn't take much to envision adding a $HOME/.local/bin to your $PATH and making a $HOME/.local/lib, etc, while you're at it.



          If you don't really want your prefix to be a hidden directory, you could easily create a symbolic link to it as well, e.g:



          ln -s .local ~/local



          Sidenote



          It is worth noting that .config (not .local/etc) is the default value for $XDG_CONFIG_HOME used for user specific config files. I should also point out that, unfortunately, a large portion of software ignores the XDG and creates config files wherever they like (usually in the root of $HOME). Also note that $XDG_CONFIG_HOME may be unset if the default $HOME/.config is desired.



          Oddly, there is no directory reserved for a distribution's default config files, so there is no way to know if a file in /etc was supplied by the distro or edited by the system administrator.






          share|improve this answer



















          • 1




            I can't find any mention of .local in the FHS
            – Daniel Serodio
            Oct 25 '17 at 17:14










          • @DanielSerodio It's in the XDG directory specification, a newer standard that it gaining prominence. See unix.stackexchange.com/questions/316765/… and superuser.com/questions/1170793/…
            – ivan_pozdeev
            Nov 7 '17 at 11:47














          up vote
          19
          down vote













          As uther mentioned, /usr/local is intended as a prefix for, essentially, software installed by the system administrator, while /usr should be used for software installed from the distribution's packages.



          The idea behind this is to avoid clashes with distributed software (such as rpm and deb packages) and give the admin full reign over the "local" prefix.



          This means that an admin can install custom compiled software while still using a distro like debian.




          From the FHS



          Software placed in / or /usr may be overwritten by system upgrades (though we recommend that distributions do not overwrite data in /etc under these circumstances). For this reason, local software must not be placed outside of /usr/local without good reason.




          When installing user-specific software, uther suggests using $HOME as the prefix since this ensures you have write permissions. Personally, I feel using $HOME/.local to be a more elegant solution, since it avoides cluttering your (hopefully) nice and tidy home directory!



          $HOME/.local/share is already used in the freedesktop.org XDG Base Directory specification, so it doesn't take much to envision adding a $HOME/.local/bin to your $PATH and making a $HOME/.local/lib, etc, while you're at it.



          If you don't really want your prefix to be a hidden directory, you could easily create a symbolic link to it as well, e.g:



          ln -s .local ~/local



          Sidenote



          It is worth noting that .config (not .local/etc) is the default value for $XDG_CONFIG_HOME used for user specific config files. I should also point out that, unfortunately, a large portion of software ignores the XDG and creates config files wherever they like (usually in the root of $HOME). Also note that $XDG_CONFIG_HOME may be unset if the default $HOME/.config is desired.



          Oddly, there is no directory reserved for a distribution's default config files, so there is no way to know if a file in /etc was supplied by the distro or edited by the system administrator.






          share|improve this answer



















          • 1




            I can't find any mention of .local in the FHS
            – Daniel Serodio
            Oct 25 '17 at 17:14










          • @DanielSerodio It's in the XDG directory specification, a newer standard that it gaining prominence. See unix.stackexchange.com/questions/316765/… and superuser.com/questions/1170793/…
            – ivan_pozdeev
            Nov 7 '17 at 11:47












          up vote
          19
          down vote










          up vote
          19
          down vote









          As uther mentioned, /usr/local is intended as a prefix for, essentially, software installed by the system administrator, while /usr should be used for software installed from the distribution's packages.



          The idea behind this is to avoid clashes with distributed software (such as rpm and deb packages) and give the admin full reign over the "local" prefix.



          This means that an admin can install custom compiled software while still using a distro like debian.




          From the FHS



          Software placed in / or /usr may be overwritten by system upgrades (though we recommend that distributions do not overwrite data in /etc under these circumstances). For this reason, local software must not be placed outside of /usr/local without good reason.




          When installing user-specific software, uther suggests using $HOME as the prefix since this ensures you have write permissions. Personally, I feel using $HOME/.local to be a more elegant solution, since it avoides cluttering your (hopefully) nice and tidy home directory!



          $HOME/.local/share is already used in the freedesktop.org XDG Base Directory specification, so it doesn't take much to envision adding a $HOME/.local/bin to your $PATH and making a $HOME/.local/lib, etc, while you're at it.



          If you don't really want your prefix to be a hidden directory, you could easily create a symbolic link to it as well, e.g:



          ln -s .local ~/local



          Sidenote



          It is worth noting that .config (not .local/etc) is the default value for $XDG_CONFIG_HOME used for user specific config files. I should also point out that, unfortunately, a large portion of software ignores the XDG and creates config files wherever they like (usually in the root of $HOME). Also note that $XDG_CONFIG_HOME may be unset if the default $HOME/.config is desired.



          Oddly, there is no directory reserved for a distribution's default config files, so there is no way to know if a file in /etc was supplied by the distro or edited by the system administrator.






          share|improve this answer















          As uther mentioned, /usr/local is intended as a prefix for, essentially, software installed by the system administrator, while /usr should be used for software installed from the distribution's packages.



          The idea behind this is to avoid clashes with distributed software (such as rpm and deb packages) and give the admin full reign over the "local" prefix.



          This means that an admin can install custom compiled software while still using a distro like debian.




          From the FHS



          Software placed in / or /usr may be overwritten by system upgrades (though we recommend that distributions do not overwrite data in /etc under these circumstances). For this reason, local software must not be placed outside of /usr/local without good reason.




          When installing user-specific software, uther suggests using $HOME as the prefix since this ensures you have write permissions. Personally, I feel using $HOME/.local to be a more elegant solution, since it avoides cluttering your (hopefully) nice and tidy home directory!



          $HOME/.local/share is already used in the freedesktop.org XDG Base Directory specification, so it doesn't take much to envision adding a $HOME/.local/bin to your $PATH and making a $HOME/.local/lib, etc, while you're at it.



          If you don't really want your prefix to be a hidden directory, you could easily create a symbolic link to it as well, e.g:



          ln -s .local ~/local



          Sidenote



          It is worth noting that .config (not .local/etc) is the default value for $XDG_CONFIG_HOME used for user specific config files. I should also point out that, unfortunately, a large portion of software ignores the XDG and creates config files wherever they like (usually in the root of $HOME). Also note that $XDG_CONFIG_HOME may be unset if the default $HOME/.config is desired.



          Oddly, there is no directory reserved for a distribution's default config files, so there is no way to know if a file in /etc was supplied by the distro or edited by the system administrator.







          share|improve this answer















          share|improve this answer



          share|improve this answer








          edited May 29 at 5:35









          Michael Homer

          42.3k6108148




          42.3k6108148











          answered Feb 20 '16 at 3:07









          MattSturgeon

          38836




          38836







          • 1




            I can't find any mention of .local in the FHS
            – Daniel Serodio
            Oct 25 '17 at 17:14










          • @DanielSerodio It's in the XDG directory specification, a newer standard that it gaining prominence. See unix.stackexchange.com/questions/316765/… and superuser.com/questions/1170793/…
            – ivan_pozdeev
            Nov 7 '17 at 11:47












          • 1




            I can't find any mention of .local in the FHS
            – Daniel Serodio
            Oct 25 '17 at 17:14










          • @DanielSerodio It's in the XDG directory specification, a newer standard that it gaining prominence. See unix.stackexchange.com/questions/316765/… and superuser.com/questions/1170793/…
            – ivan_pozdeev
            Nov 7 '17 at 11:47







          1




          1




          I can't find any mention of .local in the FHS
          – Daniel Serodio
          Oct 25 '17 at 17:14




          I can't find any mention of .local in the FHS
          – Daniel Serodio
          Oct 25 '17 at 17:14












          @DanielSerodio It's in the XDG directory specification, a newer standard that it gaining prominence. See unix.stackexchange.com/questions/316765/… and superuser.com/questions/1170793/…
          – ivan_pozdeev
          Nov 7 '17 at 11:47




          @DanielSerodio It's in the XDG directory specification, a newer standard that it gaining prominence. See unix.stackexchange.com/questions/316765/… and superuser.com/questions/1170793/…
          – ivan_pozdeev
          Nov 7 '17 at 11:47












           

          draft saved


          draft discarded


























           


          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f36871%2fwhere-should-a-local-executable-be-placed%23new-answer', 'question_page');

          );

          Post as a guest













































































          Popular posts from this blog

          How to check contact read email or not when send email to Individual?

          Displaying single band from multi-band raster using QGIS

          How many registers does an x86_64 CPU actually have?