Why is there a mix of symlinks and hardlinks in /bin?

Question

I understand the technical difference between symlinks and hardlinks, this is a question about their use in practice, particularly I'm curious to know why both are used in seemingly similar conditions: the /bin directory.

Here's a fragment its listing on my system:

~$ ls -lai /bin
total 10508
32770 drwxr-xr-x  2 root root    4096 Jun 14 11:47 .
    2 drwxr-xr-x 28 root root    4096 Sep  6 13:15 ..
  119 -rwxr-xr-x  1 root root  959120 Mar 28 22:02 bash
   2820 -rwxr-xr-x  3 root root   31112 Dec 15  2011 bunzip2
  127 -rwxr-xr-x  1 root root 1832016 Nov 16  2012 busybox
   2820 -rwxr-xr-x  3 root root   31112 Dec 15  2011 bzcat
 6191 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzcmp -> bzdiff
 5640 -rwxr-xr-x  1 root root    2140 Dec 15  2011 bzdiff
 5872 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzegrep -> bzgrep
 3520 -rwxr-xr-x  1 root root    4877 Dec 15  2011 bzexe
 6184 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzfgrep -> bzgrep
 5397 -rwxr-xr-x  1 root root    3642 Dec 15  2011 bzgrep
   2820 -rwxr-xr-x  3 root root   31112 Dec 15  2011 bzip2
 2851 -rwxr-xr-x  1 root root   10336 Dec 15  2011 bzip2recover
 6189 lrwxrwxrwx  1 root root       6 Dec 15  2011 bzless -> bzmore
 5606 -rwxr-xr-x  1 root root    1297 Dec 15  2011 bzmore

I indented the hardlinks to the same inode for better visibility. So are symlinks used in case of bzcmp, bzegrep, bzfgrep, bzless and hardlinks in case of bzip2, bzcat, bunzip2?

They are all regular files (not directories), reside inside one filesystem, are system utilities and are even made for working with the same thing: bzip archives. Are the reasons for use of hardlinks/symlinks in this particular case purely historical or am I missing something?

Clarification of my question:

I'm not asking about:

• The technical differences between symlinks and hardlinks
• The theoretical advantages and disadvantages each of them

These questions have been addressed in other threads on SO. I'm trying to understand why different decisions were made in a specific case: for a group of related system utilities. Technically, they all could've been symlinks or they all could've been hardlinks, both options would work (and in both cases a program can still figure out how it's been invoked via argv[0]). I want to understand the intent here if there is any.

Related:

• Why do hard links exist?

Answer 1

Why use hardlinks vs. Symbolic links

There are primarily 3 advantages of using hardlinks over symbolic links in this scenario.

Hard links

1. With a hard link, the link points to the inode directly.
2. Hard links are like having multiple copies of the executable but only using the disk space of one.
3. You can rename either branch of the hard link without breaking anything.

Symbolic links

1. The link points to the object (which then in-turn points to the inode).
2. They can span filesystems, whereas hardlinks cannot.

Advantages of linking in general

These links exist because many executables behave differently based on how they were called. For example the 2 commands bzless and bzmore are actually a single executable, bzmore. The executable will behave differently depending on which names was used to invoke it.

This is done for a variety of reasons. Here are some of the more obvious ones:

1. Easier to develop a single executable rather than many
2. Saves disk space
3. Easier to deploy

Why are both being used?

The choice of either, in this particular application, is moot. Either can facilitate the feature of acting as an alias so that a single executable can be overloaded. That's really the key feature that is getting exploited by the developers of the various programs here.

In looking at the FHS (Filesystem Hierarchy Standard) even specifies it this way, that it can be either.

excerpt

If /bin/sh is not a true Bourne shell, it must be a hard or symbolic link to the real shell command.

The rationale behind this is because sh and bash mightn't necessarily behave in the same manner. The use of a symbolic link also allows users to easily see that /bin/sh is not a true Bourne shell.

...

...

If the gunzip and zcat programs exist, they must be symbolic or hard links to gzip. /bin/csh may be a symbolic link to /bin/tcsh or /usr/bin/tcsh.

References

• Why are reboot, shutdown and poweroff symlinks to systemctl?

Answer 2

It seems you're trying to figure out, from existing practice, whether there is a nontechnical rule that tells you which kind of link to use. (I say nontechnical because you already know the technical reasons to use one over the other.)

The answer is, there is no other rule. This example you've pointed out from Ubuntu's bzip2 package just goes to show that a lot of developers mix them without a whole lot of forethought. This is because there is no strong guidance other than the technical differences, and those differences are small.

Personally, I prefer to use symlinks, always, because I'm willing to pay for their tiny overhead in exchange for their self-documenting nature.

Other developers will choose hard links for the tiny efficiencies they provide.

This issue is a lot like spaces vs. tabs or dynamic vs. static typing or Emacs vs. vi, save that it isn't interesting enough to spark a holy war. Like the more interesting battles, there are reasons to choose either option, but unless you have someone telling you which one to use, you get to choose the one that makes more sense to you.