mjhjmtu

I've read this link, now I simply want to know why there are lots of hard link in /usr.

For example, in my Ubuntu server, installed git, I found the command git here: /usr/bin/git. I execute ls -l /usr/bin/git and get the output as below:

-rwxr-xr-x 119 root root 11178080 Mar 6 03:48 /usr/bin/git

As you see, there are 119 hard links...

Why do we need 119 hard links here? More generally speaking, as we have the environment variable PATH and the executable files have been put into /usr/bin/, also, we can create soft links for some reason of compatibility, we can execute them anytime and anywhere, why are there some hard links in usr?

Part of output of find /usr -samefile /usr/bin/git:

/usr/libexec/git-core/git-prune
/usr/libexec/git-core/git-diff-index
/usr/libexec/git-core/git-ls-remote
/usr/libexec/git-core/git-merge-recursive
/usr/libexec/git-core/git-push
/usr/libexec/git-core/git-update-index
/usr/libexec/git-core/git-check-mailmap
/usr/libexec/git-core/git-interpret-trailers
/usr/libexec/git-core/git-archive
/usr/libexec/git-core/git-upload-archive
/usr/libexec/git-core/git-rev-parse
/usr/libexec/git-core/git-ls-files
/usr/libexec/git-core/git-am

All of hard links of /usr/bin/git are found in /usr/libexec/git-core/.

The git links have nothing to do with the PATH, they’re a space-saving measure.

Generally speaking, in most cases for “installed” software, hard links are preferable to symbolic links when possible, because they’re more efficient and resilient. You’ll see quite a few binaries in /usr/bin with hard links, including perl, and that’s fine.

git packages do tend to use symbolic links instead, because of the large number of links involved and the problems that can cause. If you install git from source, it will use hard links by default if at all possible; you can disable that by adding NO_INSTALL_HARDLINKS=1 to the make install command’s arguments.

Often, a single binary with multiple related functions has multiple hard links, in order to let each function have a distinct, memorable command, and still not duplicate any code that all those functions might have in common.

Making the various functions of a single binary appear as distinct commands is also an easy, shell-independent way to make the functions TAB-completable: for example, in bash, if you only remember the first few letters of some command, just type the letters you remember and press TAB twice: you'll get a list of all commands with those initial letters.

Symbolic links can also be used for this, but if all the linked commands are expected to be in the same directory, hard links are the most space-efficient solution: instead of duplicating an entire file, or just using up an extra inode like a symlink might do (on some filesystems), a hard link occupies just a directory entry.

If you want to, you can easily make a script behave like this too:

#!/bin/sh

case "$0##*/" in
 name1)
 # do something
 ;;
 name2)
 # do something else
 ;;
 *)
 # output an error message, or perhaps usage instructions
 ;;
esac