Pourquoi y a-t-il un mélange de liens symboliques et de liens physiques dans / bin?

Je comprends la différence technique entre les liens symboliques et les liens durs, c'est une question sur leur utilisation dans la pratique, en particulier je suis curieux de savoir pourquoi les deux sont utilisés dans des conditions apparemment similaires: l' /binannuaire.

Voici un fragment de sa liste sur mon système:

~$ 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

J'ai indenté les liens physiques vers le même inode pour une meilleure visibilité. Ainsi , sont utilisés dans le cas des liens symboliques de bzcmp, bzegrep, bzfgrep, bzlesset en cas de liens en dur bzip2, bzcat, bunzip2?

Ce sont tous des fichiers normaux (pas des répertoires), résident dans un système de fichiers, sont des utilitaires système et sont même conçus pour fonctionner avec la même chose: les archives bzip. Les raisons d'utiliser des liens physiques / liens symboliques dans ce cas particulier sont-elles purement historiques ou manque-t-il quelque chose?

Clarification de ma question:

Je ne demande pas :

• Les différences techniques entre les liens symboliques et les liens durs
• Les avantages et inconvénients théoriques de chacun d'eux

Ces questions ont été traitées dans d'autres discussions sur SO. J'essaie de comprendre pourquoi différentes décisions ont été prises dans un cas spécifique: pour un groupe d'utilitaires système connexes. Techniquement, ils auraient tous pu être des liens symboliques ou tous des liens physiques, les deux options fonctionneraient (et dans les deux cas, un programme peut toujours comprendre comment il a été invoqué via argv[0]). Je veux comprendre l'intention ici s'il y en a.

En relation:

• Pourquoi existe-t-il des liens matériels?

Pourquoi utiliser des liens physiques vs des liens symboliques

Il y a principalement 3 avantages à utiliser des liens physiques par rapport aux liens symboliques dans ce scénario.

Liens durs

1. Avec un lien dur, le lien pointe directement vers l'inode.
2. Les liens matériels sont comme avoir plusieurs copies de l'exécutable, mais uniquement en utilisant l'espace disque d'un.
3. Vous pouvez renommer l'une ou l'autre branche du lien dur sans rien casser.

Liens symboliques

1. Le lien pointe vers l'objet (qui à son tour pointe vers l'inode).
2. Ils peuvent s'étendre sur des systèmes de fichiers, contrairement aux liens physiques.

Avantages de la liaison en général

Ces liens existent car de nombreux exécutables se comportent différemment selon la façon dont ils ont été appelés. Par exemple , les 2 commandes bzlesset bzmoresont en fait un seul exécutable, bzmore. L'exécutable se comportera différemment selon les noms utilisés pour l'invoquer.

Cela se fait pour diverses raisons. Voici quelques-unes des plus évidentes:

1. Plus facile de développer un seul exécutable plutôt que plusieurs
2. Économise de l'espace disque
3. Déploiement plus simple

Pourquoi les deux sont-ils utilisés?

Le choix de l'un ou l'autre, dans cette application particulière, est théorique. L'un ou l'autre peut faciliter la fonction d'agir comme un alias afin qu'un seul exécutable puisse être surchargé. C'est vraiment la fonctionnalité clé qui est exploitée par les développeurs des différents programmes ici.

En examinant le FHS (Filesystem Hierarchy Standard), il le spécifie même de cette façon, qu'il peut être l'un ou l'autre.

extrait

Si / bin / sh n'est pas un vrai shell Bourne, il doit s'agir d'un lien dur ou symbolique vers la vraie commande shell.

La raison derrière cela est que sh et bash ne se comportent pas nécessairement de la même manière. L'utilisation d'un lien symbolique permet également aux utilisateurs de voir facilement que / bin / sh n'est pas un vrai shell Bourne.

...

...

Si les programmes gunzip et zcat existent, ils doivent être des liens symboliques ou durs vers gzip. / bin / csh peut être un lien symbolique vers / bin / tcsh ou / usr / bin / tcsh.

Références

• Pourquoi les liens symboliques de redémarrage, d'arrêt et de mise hors tension vers systemctl?

Il semble que vous essayez de déterminer, à partir de la pratique existante, s'il existe une règle non technique qui vous indique le type de lien à utiliser. (Je dis non technique parce que vous connaissez déjà les raisons techniques d'utiliser l'un sur l'autre.)

La réponse est qu'il n'y a pas d'autre règle. Cet exemple que vous avez souligné dans le bzip2package d'Ubuntu ne fait que montrer que beaucoup de développeurs les mélangent sans beaucoup de réflexion. En effet, il n'y a pas d'autre indication solide que les différences techniques, et ces différences sont faibles.

Personnellement, je préfère toujours utiliser des liens symboliques, car je suis prêt à payer pour leurs minuscules frais généraux en échange de leur nature auto-documentée.

D'autres développeurs choisiront des liens durs pour les minuscules efficacités qu'ils fournissent.

Ce problème ressemble beaucoup aux espaces vs tabulations ou à la frappe dynamique vs statique ou Emacs vs vi , sauf qu'il n'est pas assez intéressant pour déclencher une guerre sainte . Comme pour les batailles les plus intéressantes, il y a des raisons de choisir l'une ou l'autre option, mais à moins que quelqu'un ne vous dise laquelle utiliser, vous pouvez choisir celle qui vous convient le mieux.