Links in /usr/bin or /usr/local/bin: hard or symbolic?

Question

For the links located in /usr/bin and in /usr/local/bin, are they better to be hard or symbolic? They seem to be all symbolic? Why?

Solution

When links are put in /usr/bin or /usr/local/bin, this is often because the actual binary is living somewhere else. Why is it living somewhere else? Usually because it is a part of a group of files, often in its own subdirectory, which it depends on to run. Why can't all those files be dumped into /usr/bin or /usr/local/bin? Because those locations are only for binaries, the binaries live at the top level of those directories, and no subdirectories are allowed.

So, why don't we use a hard link there? Because a hard link to a file is considered to be of equal status to the original file (it shares the same inode) and the file will not be deleted while there is a hard link to it. In contrast, a symbolic link is simply a pointer to "the real thing". In practice, putting a hard link to a binary file that is living somewhere else wouldn't make much sense, because if those other files in that other location/subdirectory were removed, the file could not function by itself.

An example of this are the various TeX utilities, which live in /usr/bin. If you look at them, you will see that many of them point to files that are actually in /usr/share/texlive/texmf-dist/scripts/. You can see these, for example, by doing ls -la | grep texmf.

As muru mentions, another reason is that hard links don't work across filesystems.

Another situation in which links are used for files in /usr/bin or /usr/local/bin is Debian's alternatives system. In this case, a binary may be a symbolic link pointing to a symbolic link in /etc/alternatives, which then points to the actual binary, often again itself in /usr/bin.

Example:

ls -la /usr/bin/awk 
lrwxrwxrwx 1 root root 21 Jul 31  2013 /usr/bin/awk -> /etc/alternatives/awk
ls -la /etc/alternatives/awk
lrwxrwxrwx 1 root root 13 Aug 11  2013 /etc/alternatives/awk -> /usr/bin/gawk

It is fairly obvious in this case that a symbolic link is the correct mechanism, because it is pointing to any of a range of possible binaries.

Comments

[muru]

Why not? Also: 1. While dangling links might be a concern, at least the app is deleted when the source of the link is deleted, unlike with hardlinks. 2. Links across filesystems.

[inVader]

While the rest of your argumentation is valid and makes complete sense to me, the following statement is not true: Also, the hard link might not work in any case, because it wouldn't follow the actual link to its "actual" location (untested). The binary wouldn't know its location and relative paths would always be in respect to the current working directory, not the directory of the binary (or its hardlink).

[Alen Milakovic]

@inVader just to explicate what I had in mind - suppose you have a binary /usr/bin/foo, which is actually a symlink to /usr/share/foolib/foo. Now, the latter file might depend on other files in /usr/share/foolib, via say relative paths. If it did, then if /usr/bin/foo was a hardlink as opposed to a symlink, it would break, because the hardlink /usr/bin/foo would be looking for those files in the wrong place. But off the top of my head I don't have an example of this.

[inVader]

But if I call /usr/share/foolib/foo from my home directory, than all relative paths are relative to my home dir not to the directory the binary is in. The binary would have to know that it and its depending files are supposed to be in /usr/share/foolib, at which point it should no longer matter whether we have a hard or a symbolic link. I might be wrong, but I really do not see a way in which the binary would actually figure out its own location, then expect files to be in the same directory.