I'm about to install Leiningen which is a useful Bash script for the Clojure programming language.

The problem is, I'm not sure where it is appropriate to put a executable script in the Linux system so that it's permanently and stable-ly available.

I don't think that anywhere in /home makes sense, but I don't know which directories are supposed to be used for that.



5 Answers 5


(Note: ~ translates as /home/user in this post)

Personally, I put all of my custom-made system scripts in /usr/local/bin and all of my personal bash scripts in ~/bin. Very few programs I install place themselves in /usr/local/bin directory so it's not very cluttered and it was already in the $PATH variable on most of my machines.

To add /usr/local/bin to your system path (if it's not already there) add this to /etc/profile:

export PATH

To add ~/bin to your user's path add this to ~/.bash_profile:

export PATH

Sometimes the default .bash_profile file will have an if statement that automatically adds ~/bin to $PATH if it exists, so create the ~/bin and open a new terminal to see if yours already does this.

  • The BSDs do this by default.
    – Chris S
    May 7, 2010 at 3:47
  • @Chris: BSDs put a lot of stuff in /usr/local/bin May 7, 2010 at 11:25
  • What's the difference between your bash scripts and system scripts, and is there a reason you separate the two? Apr 9, 2019 at 4:48
  • @Hashim I can't speak for Trey of course, but tools you develop for your personal needs tend to "graduate" to system tools when you notice they solve a problem others are struggling with, or you have another system-wide install which depends on one of these tools. I suspect the threshold to install something system-wide is rather high for most programmers. Also, a tool you share needs to have documentation etc which many developers rarely write otherwise.
    – tripleee
    Jun 29, 2019 at 6:36
  • As an aside, there's no need to export a variable multiple times (and probably your system already marked PATH for export, so you don't have to do it yourself at all).
    – tripleee
    Jun 29, 2019 at 6:38

/usr/local/ is really the right place, while /opt is really for third party applications; "/opt is reserved for the installation of add-on application software packages." This is part of the Filesystem Hierarchy Standard.

See http://www.pathname.com/fhs/pub/fhs-2.3.html for discussion on /opt.

For /usr/local/, it is for "use by the system administrator". Just don't forget about stuff in there -- document it.

  • The link that you provided tells "The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man are reserved for local system administrator use." There is nothing about /usr/local. Only /usr/local/share is mentioned there. On the other hand, compiled programs are usually installed into /usr/local on Linux. Don't you think /opt/bin is better place for use by the system administrator?
    – raacer
    Oct 31, 2015 at 0:16
  • 1
    @raacer My experience is that /usr/local - like the name implies - is for the local admin, and /opt for things which are not officially distributed, like commercial third-party software which is managed by a similar process (might be replaced or wiped in an upgrade from upstream) but not managed by the distro's package manager, or perhaps actually distributed as RPM or .deb packages, but not organized and packaged in adherence with all the distro's policies and conventions.
    – tripleee
    Jun 29, 2019 at 6:51
  • 1
    @raacer There is a separate section entirely about /usr/local later in the document.
    – tripleee
    Jun 29, 2019 at 8:08
  • @raacer tripleee is right. Here's the link: pathname.com/fhs/pub/… .. correct, compiled programs (usually open source) that are compiled/built specifically for that system or shared between several systems (but not part of the normal OS packaging/distribution, but that rely heavily on shared libs) should be installed into /usr/local (basically mirrors the hierarchy of /usr). Third party software that are compiled on a possibly different system with possibly their own library support (i.e., firefox, userify) should go into /opt. Jun 29, 2019 at 15:29

Historically you'd use something like /opt. Anything is fine as long as it's updated in $PATH for the users who are supposed to have it (hence anything in /home being a bad idea).


/usr/share/clojure seems like a common place to put clojure's binaries and libraries — why I don't know, it seems a natural for /usr/local/share/clojure— so creating a site subdirectory under this for these bash scripts seems fine.

The general point is that it makes more sense to organise scripts by function, not have all bash scripts in the same place.

  • 1
    There is a couple of problems using /usr/share for this. First of all share means architecture independent files (i.e. shared across architectures). For that reason libraries and executables do not belong under a share directory. Secondly except from /usr/local nothing other than the distribution package manager should ever write to /usr.
    – kasperd
    Dec 14, 2018 at 15:34

/usr/local, I believe there's some confusion to the meaning of "local".

As I understand it, "local" doesn't mean "originating on/from the local machine" but, more simply, "specific to the local machine", which may or may not originate on/from the local machine.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.