Return to Answer

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. Also, the hard link might not work in any case, because it wouldn't follow the actual link to its "actual" location (untested).

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.

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.

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.

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. Also, the hard link might not work in any case, because it wouldn't follow the actual link to its "actual" location (untested).

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.

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 this is used 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.

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.