You generally do not link
/bin, but this is more of a historical practice. In general, there are a few "technical" reason why you cannot do what you're suggesting.
Making links to executables in
/bin can cause problems:
Probably the biggest caveat would be if you're system is having packages managed by some sort of package manager such as RPM, dpkg, APT, YUM, pacman, pkg_add, etc. In these cases, you'll generally want to let the package manager do its job and manage directories such as
/usr. One exception would be
/usr/local which is typically a safe place to do as you see fit on the box, without having to worry about a package manager interfering with your files.
Often times executables built for
/usr/local will have this PATH hard-coded into their executables. There may also be configuration files that are included in
/usr/local as part of the installation of these applications. So linking to just the executable could cause issues with these apps finding the
.cfg files later one. Here's an example of such a case:
$ strings /usr/local/bin/wit | grep '/usr/local'
The same issue that applies to finding
.cfg files can also occur with "helper" executables that the primary app needs to run. These too would also need to be linked into
/usr/bin, knowing this might be problematic and only show up when you actually attempted to execute the linked app.
NOTE: in general it's best to avoid the temptation to link to one off apps in
Rather then have all the users provide this management, the admin could very easily add this to everyone's
$PATH on the box by adding a corresponding file in the
A file such as this,
You generally do this as an admin instead of polluting all the users' setups with this.
Most distros now provide another tool called
alternatives (Fedora/CentOS) or
update-alternatives (Debian/Ubuntu) which you can also use to loop into the
$PATH tools which might be outside the
/bin. Using tools such as these is preferable since these are adhering more to what most admins would consider "standard practice" and so makes the systems easier to hand off from one admin to another.
This tool does a similar thing in making links in
/bin; but it manages the creation and destruction of these links, so it's easier to understand a system's intended setup when done through a tool vs. done directly as you're suggesting.
Here I'm using that system to manage Oracle's Java on a box:
$ ls -l /etc/alternatives/ | grep " java"
lrwxrwxrwx. 1 root root 73 Feb 5 13:15 java -> /usr/lib/jvm/java-1.7.0-openjdk-18.104.22.168-22.214.171.124.fc19.x86_64/jre/bin/java
lrwxrwxrwx. 1 root root 77 Feb 5 13:15 java.1.gz -> /usr/share/man/man1/java-java-1.7.0-openjdk-126.96.36.199-188.8.131.52.fc19.x86_64.1.gz
lrwxrwxrwx. 1 root root 70 Feb 5 13:19 javac -> /usr/lib/jvm/java-1.7.0-openjdk-184.108.40.206-220.127.116.11.fc19.x86_64/bin/javac
lrwxrwxrwx. 1 root root 78 Feb 5 13:19 javac.1.gz -> /usr/share/man/man1/javac-java-1.7.0-openjdk-18.104.22.168-22.214.171.124.fc19.x86_64.1.gz
lrwxrwxrwx. 1 root root 72 Feb 5 13:19 javadoc -> /usr/lib/jvm/java-1.7.0-openjdk-126.96.36.199-188.8.131.52.fc19.x86_64/bin/javadoc
lrwxrwxrwx. 1 root root 80 Feb 5 13:19 javadoc.1.gz -> /usr/share/man/man1/javadoc-java-1.7.0-openjdk-184.108.40.206-220.127.116.11.fc19.x86_64.1.gz
You can see the effects of this:
$ type java
java is /usr/bin/java
$ readlink -f /usr/bin/java
Making links in
/bin, though plausible, would likely be highly discouraged by most sysadmins:
- Would be frowned upon because it's viewed as custom and can lead to confusion if another admin is required to pick up the box
- Can lead to a system becoming broken at a future state as a result of this "fragile" customization.