33

I'm about to install "leiningen" which is a bash script for the clojure programming language with a lot of usefulness... ...but 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 directory/directories are supposed to be used for that.

/usr/share?

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.

| improve this answer | |
  • The BSDs do this by default. – Chris S May 7 '10 at 3:47
  • @Chris: BSDs put a lot of stuff in /usr/local/bin – Dan Andreatta May 7 '10 at 11:25
  • What's the difference between your bash scripts and system scripts, and is there a reason you separate the two? – Prometheus Apr 9 '19 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 '19 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 '19 at 6: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.

| improve this answer | |
  • 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 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 '19 at 6:51
  • 1
    @raacer There is a separate section entirely about /usr/local later in the document. – tripleee Jun 29 '19 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. – 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).

| improve this answer | |
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.

| improve this answer | |
  • 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.

| improve this answer | |

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.