167

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?

Valerio Bozz
  • 403
user640378
  • 1,963

4 Answers4

171

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 or $HOME/.local/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 or $HOME/.local directory. Using $HOME, 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 in 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.

Matthias Braun
  • 8,239
George M
  • 13,959
  • Thanks for your answer!

    So, as per the convention, I can have directories like bin, lib, tmp in my $HOME. Correct me if I'm wrong.

     – user640378 Apr 19 '12 at 14:52
  • You certainly can. – George M Apr 19 '12 at 15:01
  • 6
    as long as $HOME is not on a noexec mounted filesystem. /tmp/ is usually mounted noexec too. – ewanm89 Apr 19 '12 at 17:24
  • 4
    This is correct, its part of the Filesystem Hierarchy Standard (FHS). http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY – phemmer Apr 19 '12 at 22:58
  • 49
    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 03 '12 at 00:43
  • 1
    Agreed, I wonder why anybody wants to pollute $HOME by 10 more directories (in addition to dozens dot-files). – maaartinus Jun 05 '12 at 22:45
  • 40
    One option is to use $HOME/.local/{bin,lib,etc.}, as used by e.g. the XDG basedir spec (http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html ) and python (http://www.python.org/dev/peps/pep-0370/ ) – janneb May 28 '13 at 19:20
  • 6
    @janneb The XDG Base Directory Specification you refer to mentions only $HOME/.local/share (Version 0.7, 24th November 2010). – Piotr Dobrogost Nov 03 '15 at 22:06
  • 3
    There's also $HOME/.local/bin as used by Python PIP with the --user flag. – CMCDragonkai Nov 03 '16 at 09:46
  • 1
    agree with Marco and janneb, after 20 years of building software on other peoples machines in my home didrectory. i used to use $HOME/sys alot as a target for ./configure --prefix=$HOME/sys, but nowdays i would probably use ./configure --prefix=$HOME/.local – don bright Aug 23 '17 at 01:00
  • 1
    What about ~/.local/bin? Then it wouldn't be splattering directories all over the home folder. – Aaron Franke Dec 30 '18 at 02:46
  • I go a step further: I configure each local piece of software with a dedicated prefix. It's perfect for software that you try once from source and may not keep. And if you like it do a symlink from ~/bin. Wrote a script to automate it for autotools and cmake cases: https://github.com/fidergo-stephane-gourichon/source_to_executable_quick – Stéphane Gourichon Jan 04 '20 at 14:35
51

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 avoids cluttering your (hopefully) nice and tidy home directory!

$HOME/.local/share and $HOME/.local/bin are already used in the freedesktop.org XDG Base Directory specification, and distributions are requested to add $HOME/.local/bin to the $PATH, so it doesn't take much to envision 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.

Stephen Kitt
  • 434,908
MattSturgeon
  • 748
  • 1
    I can't find any mention of .local in the FHS – Daniel Serodio Oct 25 '17 at 17:14
  • 1
    @DanielSerodio It's in the XDG directory specification, a newer standard that it gaining prominence. See https://unix.stackexchange.com/questions/316765/which-distributions-have-home-local-bin-in-path and https://superuser.com/questions/1170793/why-is-local-share-a-two-level-directory – ivan_pozdeev Nov 07 '17 at 11:47
8

The XDG Base Directory Specification Version 0.8 states local executables should be placed in ~/.local/bin:

User-specific executable files may be stored in $HOME/.local/bin. Distributions should ensure this directory shows up in the UNIX $PATH environment variable, at an appropriate place.

If your distro is following the specification you should therefore not have to "explicitly include the path." This previous question tries to ascertain which distributions do this.

Concrete_Buddha
  • 246
6

It looks like /usr/local/bin according to the Internet website Wikitechy.

Information about /usr/bin from Filesystem Hierarchy Standard, they define the folder as the primary directory of executable commands on the system.

Additional information between /usr/bin vs. /usr/local/bin from the Wikitechy:

  /usr/bin is the location for the OS supplied executables that are used by common users. For example, not typically core operating system required files, or root user accessed files, but can be.

  /usr/local/bin is the location for all add-on executables that you add to the system to be used as common system files by all users but, are not official files supported by the OS.

   Overall, /usr/bin is where binaries supplied by the OS. /usr/local/bin is where user downloaded binaries.

Cloud Cho
  • 167
  • /usr/bin is a system directory with root ownership, regular users cannot (and shouldn't if they could) copy their executables into there. – thanasisp Nov 08 '20 at 06:42
  • @thanasisp thanks for the information. Isn't your statement based on assumption of Linux Server case? I don't think if you use your own Linux computer, it won't be prohibited to use /usr/bin...Isn't the question from a Linux personal computer user? Please, share some web link regarding personal computer users. – Cloud Cho Nov 09 '20 at 17:43
  • 1
    I assume any computer, on my home pc for example, I have a separated installation of python (different versions) in my ~/.local/ I never touch the system python, it's used by the system, and in general I never use the root account or edit any system directory, unless if I need to do something system-wide, like updating, configuring a service, etc. It's a recommended practice to avoid mistakes also. – thanasisp Nov 09 '20 at 17:54
  • @thanasisp thanks for sharing your practice. I searched the Internet and updated my answer. – Cloud Cho Nov 09 '20 at 18:49