Por que existe uma mistura de links simbólicos e hardlinks em / bin?

Entendo a diferença técnica entre links simbólicos e links físicos, essa é uma pergunta sobre o uso deles na prática, particularmente estou curioso para saber por que os dois são usados ​​em condições aparentemente semelhantes: o /bindiretório.

Aqui está um fragmento de sua listagem no meu 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

Recuei os hardlinks no mesmo inode para melhor visibilidade. Então são links simbólicos utilizados em caso de bzcmp, bzegrep, bzfgrep, bzlesse hardlinks no caso de bzip2, bzcat, bunzip2?

Todos são arquivos comuns (não diretórios), residem em um sistema de arquivos, são utilitários de sistema e são criados para trabalhar com a mesma coisa: arquivos bzip. As razões para o uso de links físicos / links simbólicos neste caso específico são puramente históricas ou estou perdendo alguma coisa?

Esclarecimento da minha pergunta:

Eu não estou perguntando sobre:

• As diferenças técnicas entre links simbólicos e hardlinks
• As vantagens e desvantagens teóricas de cada uma delas

Essas perguntas foram abordadas em outros threads no SO. Estou tentando entender por que decisões diferentes foram tomadas em um caso específico: para um grupo de utilitários de sistema relacionados. Tecnicamente, todos eles poderiam ter sido links simbólicos ou todos eles poderiam ter sido links físicos, ambas as opções funcionariam (e em ambos os casos um programa ainda pode descobrir como foi chamado argv[0]). Eu quero entender a intenção aqui, se houver.

Palavras-chave:

• Por que existem links físicos?

Por que usar hardlinks x links simbólicos

Existem basicamente três vantagens em usar links físicos sobre links simbólicos nesse cenário.

Links físicos

1. Com um link físico, o link aponta diretamente para o inode.
2. Os links físicos são como ter várias cópias do executável, mas usando apenas o espaço em disco de um.
3. Você pode renomear qualquer ramo do link físico sem interromper nada.

Links simbólicos

1. O link aponta para o objeto (que, por sua vez, aponta para o inode).
2. Eles podem abranger sistemas de arquivos, enquanto os hardlinks não.

Vantagens da ligação em geral

Esses links existem porque muitos executáveis ​​se comportam de maneira diferente com base em como foram chamados. Por exemplo, os 2 comandos bzlesse bzmoresão realmente um único executável bzmore,. O executável se comportará de maneira diferente, dependendo de quais nomes foram usados ​​para invocá-lo.

Isso é feito por vários motivos. Aqui estão alguns dos mais óbvios:

1. Mais fácil desenvolver um único executável do que muitos
2. Economiza espaço em disco
3. Mais fácil de implantar

Por que ambos estão sendo usados?

A escolha de qualquer um, nesta aplicação específica, é discutível. Qualquer um pode facilitar o recurso de atuar como um alias para que um único executável possa ser sobrecarregado. Essa é realmente a principal característica que está sendo explorada pelos desenvolvedores dos vários programas aqui.

Ao olhar para o FHS (padrão de hierarquia do sistema de arquivos) , ele ainda o especifica dessa maneira, que também pode ser.

excerto

Se / bin / sh não for um shell Bourne verdadeiro, deve ser um link rígido ou simbólico para o comando shell real.

A lógica por trás disso é que sh e bash podem não necessariamente se comportar da mesma maneira. O uso de um link simbólico também permite que os usuários vejam facilmente que / bin / sh não é um shell Bourne verdadeiro.

...

...

Se os programas gunzip e zcat existirem, eles deverão ser links simbólicos ou físicos para o gzip. / bin / csh pode ser um link simbólico para / bin / tcsh ou / usr / bin / tcsh.

Referências

• Por que os links simbólicos de reinicialização, desligamento e poweroff para systemctl?

Parece que você está tentando descobrir, a partir da prática existente, se existe uma regra não técnica que diz a você que tipo de link usar. (Digo não técnico, porque você já conhece os motivos técnicos para usar um sobre o outro.)

A resposta é que não há outra regra. Este exemplo que você apontou no bzip2pacote do Ubuntu mostra apenas que muitos desenvolvedores os misturam sem muita premeditação. Isso ocorre porque não há orientação forte além das diferenças técnicas, e essas diferenças são pequenas.

Pessoalmente, prefiro usar links simbólicos, sempre, porque estou disposto a pagar por sua pequena sobrecarga em troca de sua natureza de auto-documentação.

Outros desenvolvedores escolherão links físicos para as pequenas eficiências que fornecem.

Esse problema é muito parecido com espaços versus guias ou digitação dinâmica vs. estática ou Emacs vs. vi , exceto que não é interessante o suficiente para desencadear uma guerra santa . Como nas batalhas mais interessantes, há razões para escolher qualquer uma das opções, mas, a menos que você tenha alguém lhe dizendo qual usar, você poderá escolher a que mais faz sentido para você.