35

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.

/usr/share?

Matthias Braun
  • 225
  • 1
  • 8
Kzqai
  • 1,278
  • 4
  • 18
  • 32

5 Answers5

47

(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:

PATH=$PATH:/usr/local/bin
export PATH

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

PATH=$PATH:$HOME/bin
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.

Trey Hunner
  • 1,282
  • 10
  • 9
  • The BSDs do this by default. – Chris S May 07 '10 at 03:47
  • @Chris: BSDs put a lot of stuff in /usr/local/bin – Dan Andreatta May 07 '10 at 11:25
  • What's the difference between your bash scripts and system scripts, and is there a reason you separate the two? – Hashim Aziz Apr 09 '19 at 04: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 '19 at 06: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 '19 at 06:38
9

/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.

fatal_error
  • 1,152
  • 1
  • 11
  • 18
  • 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 '15 at 00: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 '19 at 06:51
  • 1
    @raacer There is a separate section entirely about `/usr/local` later in the document. – tripleee Jun 29 '19 at 08:08
  • @raacer tripleee is right. Here's the link: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLTQUALGTALTERNATEFORMATLIBRARI .. 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. – fatal_error Jun 29 '19 at 15:29
3

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).

Tony
  • 482
  • 3
  • 3
2

/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.

Charles Stewart
  • 650
  • 6
  • 19
  • 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 '18 at 15:34
2

/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.

kasperd
  • 30,455
  • 17
  • 76
  • 124
Ate Somebits
  • 157
  • 9