Perché c'è un mix di symlink e hardlink in / bin?

Capisco la differenza tecnica tra symlink e hardlink, questa è una domanda sul loro uso in pratica, in particolare sono curioso di sapere perché entrambi sono usati in condizioni apparentemente simili: la /bindirectory.

Ecco un frammento del suo elenco sul mio sistema:

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

Ho indentato i hardlink sullo stesso inode per una migliore visibilità. Così sono i collegamenti simbolici utilizzati in caso di bzcmp, bzegrep, bzfgrep, bzlesse collegamenti fisici in caso di bzip2, bzcat, bunzip2?

Sono tutti file regolari (non directory), risiedono all'interno di un file system, sono utilità di sistema e sono persino creati per lavorare con la stessa cosa: archivi bzip. I motivi per l'uso di hardlink / symlink in questo caso particolare sono puramente storici o mi sto perdendo qualcosa?

Chiarimento della mia domanda:

Sto Non chiedendo:

• Le differenze tecniche tra symlink e hardlink
• I vantaggi e gli svantaggi teorici di ciascuno di essi

Queste domande sono state affrontate in altri thread su SO. Sto cercando di capire perché sono state prese diverse decisioni in un caso specifico: per un gruppo di utilità di sistema correlate. Tecnicamente, avrebbero potuto essere tutti collegamenti simbolici o tutti potevano essere collegamenti fissi, entrambe le opzioni avrebbero funzionato (e in entrambi i casi un programma può ancora capire come è stato invocato tramite argv[0]). Voglio capire l'intento qui se ce n'è.

Relazionato:

• Perché esistono collegamenti reali?

Perché usare hardlink vs. link simbolici

In questo scenario ci sono principalmente 3 vantaggi nell'utilizzare hardlink rispetto a link simbolici.

Collegamenti reali

1. Con un collegamento reale, il collegamento punta direttamente all'inode.
2. I collegamenti fisici sono come avere più copie dell'eseguibile ma usando solo lo spazio su disco di uno.
3. È possibile rinominare uno dei rami del collegamento reale senza interrompere nulla.

Collegamenti simbolici

1. Il collegamento punta all'oggetto (che quindi a sua volta punta all'inode).
2. Possono estendersi ai filesystem, mentre i collegamenti fisici no.

Vantaggi del collegamento in generale

Questi collegamenti esistono perché molti eseguibili si comportano in modo diverso in base al modo in cui sono stati chiamati. Ad esempio i comandi 2 bzlesse bzmoresono in realtà un unico eseguibile, bzmore. L'eseguibile si comporterà in modo diverso a seconda dei nomi utilizzati per invocarlo.

Questo viene fatto per una serie di motivi. Ecco alcuni dei più ovvi:

1. Più facile da sviluppare un singolo eseguibile piuttosto che molti
2. Risparmia spazio su disco
3. Più facile da implementare

Perché entrambi vengono utilizzati?

La scelta di uno, in questa particolare applicazione, è discutibile. Entrambi possono facilitare la funzione di agire come alias in modo che un singolo eseguibile possa essere sovraccaricato. Questa è davvero la caratteristica chiave che viene sfruttata dagli sviluppatori dei vari programmi qui.

Guardando il FHS (Filesystem Hierarchy Standard) lo specifica anche in questo modo, che può essere uno dei due.

estratto

Se / bin / sh non è una vera shell Bourne, deve essere un collegamento rigido o simbolico al comando shell reale.

La logica alla base di ciò è perché sh e bash potrebbero non comportarsi necessariamente nello stesso modo. L'uso di un collegamento simbolico consente inoltre agli utenti di vedere facilmente che / bin / sh non è una vera shell Bourne.

...

...

Se esistono i programmi gunzip e zcat, devono essere collegamenti simbolici o concreti a gzip. / bin / csh può essere un collegamento simbolico a / bin / tcsh o / usr / bin / tcsh.

Riferimenti

• Perché i link simbolici di riavvio, spegnimento e spegnimento di systemctl?

Sembra che tu stia cercando di capire, dalla pratica esistente, se esiste una regola non tecnica che ti dice quale tipo di collegamento usare. (Dico non tecnico perché conosci già i motivi tecnici per usarne uno rispetto all'altro.)

La risposta è che non esiste altra regola. Questo esempio che hai sottolineato dal bzip2pacchetto di Ubuntu dimostra semplicemente che molti sviluppatori li mescolano senza pensarci troppo. Questo perché non esiste una guida forte oltre alle differenze tecniche e queste differenze sono piccole.

Personalmente, preferisco usare i symlink, sempre, perché sono disposto a pagare per le loro piccole spese generali in cambio della loro natura autocompensante.

Altri sviluppatori sceglieranno hard link per le piccole efficienze che forniscono.

Questo problema è molto simile agli spazi rispetto alle schede o alla digitazione dinamica rispetto a statica o a Emacs vs vi , salvo che non è abbastanza interessante da scatenare una guerra santa . Come le battaglie più interessanti, ci sono ragioni per scegliere entrambe le opzioni, ma a meno che tu non abbia qualcuno che ti dice quale usare, puoi scegliere quella che ha più senso per te.