Unix standard directory to put custom executables or scripts?

Question

If I have a custom shell script or programs, that I created myself or downloaded from the web, and I want to be able to execute this from the CLI, is there the standard location to put this in Linux/Unix directory structure?

/usr/bin ?
/usr/local/bin ?
/usr/lib ?
/usr/sbin ?
/bin ?
/sbin ?
/var ?

I usually put it under my ~/bin folder and put it in PATH, but it doesn't seem clean. And everytime I downloaded a new program, I have to put it in the PATH again.

Solution 1

/usr/local/bin exists precisely for this purpose: for system-wide installation. For your own private use, ~/bin is the de facto standard.

If you want to keep each binary in its own subdirectory, you can do that, and add a symlink to a directory already in your PATH. So, for example:

curl -o $HOME/downloads/fnord http://fnord.example.com/script.exe
ln -s $HOME/downloads/fnord $HOME/bin/

This assumes $HOME/bin is in your PATH.

There are tools like stow which do this -- and much more -- behind the scenes for you.

Solution 2

This may vary slightly depending on the Unix flavour. I'm assuming Linux here (although this could apply to OSX). According to the Filesystem Hierarchy Standard (FHS) (link obtained from the Linux Standard Base working group):

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.

/usr/local/bin is often on the path by default.

Note that you should only put the executable or a link to it in /usr/local/bin, the rest may have to go in /usr/local/lib or /usr/local/share.

The /opt tree might also be sensible:

/opt is reserved for the installation of add-on application software packages.

A package to be installed in /opt must locate its static files in a separate /opt/<package> or /opt/<provider> directory tree, where <package> is a name that describes the software package and <provider> is the provider's LANANA registered name.

[...]

The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man are reserved for local system administrator use. Packages may provide "front-end" files intended to be placed in (by linking or copying) these reserved directories by the local system administrator, but must function normally in the absence of these reserved directories.

(You could make your own link from /opt/your-package/bin/executable into /opt/bin, and put /opt/bin on the PATH if it's not already there.)

Comments

[Henrik]

As a tip for Mac users: If you choose ´~/bin´ and don't want this directory to show up i Finder, you can make it invisible with SETFILE(1): ´setfile -a V ~/bin´ for making invisible and ´setfile -a v ~/bin´ for making visible again. Note that this requires the Xcode Tools.

[phs]

@tripleee: Is there a de facto standard directory for scripts (bash, perl, etc.) ? I'm thinking of e.g. ~/etc? The point is that you do not backup/track with a cvs/.. in the same way scripts and binaries.

[tripleee]

@phs bin is for all kinds of executables, scripts or proper binaries. If you want them under direct version control, putting all of your bin in version control is certainly an option; though more commonly, you have a separate project for each, or at least each distinct group. When you release a new version, install it into your own bin. Or if you're serious about dog-fooding and/or have too few surprises in your life, put a symlink to your development version in your bin.

[capitano666]

Thanks, I did a ln -s /usr/local/bin /root/ to better keep track of executables and respect both standards ;)

[tripleee]

@capitano666 Not sure what you means with "both standards". The home directory of root should normally contain very little, as it's for stuff which is useful to root only.

[capitano666]

@tripleee in my case root is the only one allowed to modify the /usr/local/bin contents. Nevermind though, I was just pointing out that my symlink happened to conform to what you called the "de facto standard"

[tripleee]

I don't see the benefit. /usr/local/bin should go early in your PATH; duplicating the same entries as symlinks in another directory in your PATH will only make path searches slower.

[Joseph Nields]

I use ~/bin and add the line export $PATH=$PATH:~/bin to ~/.bash_profile so that I can have this be a part of $PATH when I log on. I only keep the executable binaries here, though - no downloads.

[tripleee]

As an aside, there would normally not be any reason to export this variable again; it will already have been exported by the shell.

[tripleee]

@erm3nda sbin isn't actually for sudo specifically. This directory generally contains executables which are not useful to non-admin users.

[m3nda]

@tripleee is that true for all distros? thx

[tripleee]

More than that, this is by no means just Linux, though I believe it's also codified in the LSB.