Adding a new directory to PATH vs. a symlink for directory already in PATH

Question

In setting it up so I could execute Sublime Text from bash, I discovered two methods of doing this via different tutorials:

Method 1) Create a symlink from /usr/local/bin/subl to Sublime's bin dir:

sudo ln -s /Applications/Sublime\ Text.app/Contents/SharedSupport/bin/subl /usr/local/bin/subl

This took advantage that /usr/local/bin is already in my PATH variable.

...or...

Method 2) Update your PATH to include the path to Sublime's bin folder:

export PATH="/Applications/Sublime Text.app/Contents/SharedSupport/bin/":$PATH

Both work, but I'm wondering if one method is better than the other, or are they equally fine?

The only advantage I can potentially see is for Method 1 if is if it's beneficial to have less dirs in your PATH directory (speed/performance in looking for the executable?).

Solution 1

If you are looking for way to run/execute program/script as a command directly from terminal, then I think putting scripts or links to /usr/local/bin is good choice!

Also the advantage is that it is already in path. Visit this related post.

But if a program directory provides several executables, then I think exporting path of that directory may useful/better than creating several symlinks individually.

Solution 2

Adding a symlink to a directory already in your PATH is often preferable.

If you want the software to be visible system-wide (by other users), add a symlink to /usr/local/bin. If you want the software to be visible only by you, add once $HOME/bin/ to your PATH (some distributions are configuring the bash shell to add that directory automagically if it exists) and add symlinks from it.

You should avoid having a very long PATH (so avoid adding a directory in it for every newly installed applications), both for performance (but some shells are caching PATH lookup, so that might not matter that much) and for maintainability purposes (you'll have a mess if your PATH contain dozens of directories); this is also true for LD_LIBRARY_PATH (so better add symlinks from $HOME/lib/ ...).

You might also consider using GNU stow which partly automate the process (I tried to use it a few years ago, but felt that it is not worth the burden).

At last, many software that you compile from source code can be configured to be installed somewhere else than under /usr/local/ and its /usr/local/bin/ directory. For free software configured with GNU autoconf facilities (i.e. having a configure script generated from configure.ac....), you may want to pass --prefix=$HOME/pub/ --exec-prefix=$HOME/bin/ and some other options (e.g. --program-suffix=-mine, ...) at build time.

A third method of doing would be to wrap your executable in some shell script which export-s an augmented PATH e.g. using export PATH=$PATH:/opt/something/bin .... (this is necessary if the executable is forking more internal processes executed thru execvp); BTW most firefox installations are doing that (so firefox or mozilla would be a shell script ending with exec mozilla.bin ....), or in a script which end by exec-ing the full path. so you might simply add a small shell script as $HOME/bin/sublimetext (assuming $HOME/bin/ is already in your PATH) containing

#!/bin/sh
# file $HOME/bin/sublimetext
# if needed add export PATH=$PATH:/Applications/Sublime\ Text.app/Contents/SharedSupport/bin 
exec /Applications/Sublime\ Text.app/Contents/SharedSupport/bin/subl "$@"

and you could even name that script $HOME/bin/subl if you want to; don't forget to make your script executable with chmod u+rx $HOME/bin/subl

Comments

[Janis]

Your conclusion is absolutely correct. - Mind also, that you would get horrendous (unmaintainable) PATH definitions if every application would add its own path to PATH. - Note, though; if the program shall only be accessible for your account (not for all users), better put in your local $HOME/bin and add that to your PATH in your own shell profile.

[Mingye Wang]

When using method 2, it might be safer to use export PATH="$PATH:/Applications/Sublime Text.app/Contents/SharedSupport/bin/" so the sbt stuffs don't come before original system binaries. For OS X, you may also add one file named, say, 80-sbt in /etc/paths.d containing the line /Applications/Sublime Text.app/Contents/SharedSupport/bin/.

[Niing]

@Arthur2e5: Why it's 80-sbt not 79-sbt?

[Mingye Wang]

@Niing The two digit numbers that go before filenames help sort out the sequence of inclusion naturally by a glob like *. There isn't really a reason to pick 80 over 79; I just went for a number that is not very early so as not to interfere with other stuff.

[Niing]

So I can't create a symlink of ...some_app/bin that would do the same as export PATH=...?

[Niing]

So I can't create a symlink of ...some_app/bin that would do the same as export PATH=...?