Um é provavelmente um link simbólico (ou link físico) para o outro, mas eles são o mesmo arquivo.
O / etc / shells diz que tem zsh instalado em /bin/zsh , mas também em /usr/bin/zsh .
brgr@envy17:~$ cat /etc/shells
# /etc/shells: valid login shells
/bin/sh
/bin/dash
/bin/bash
/bin/rbash
/usr/bin/tmux
/usr/bin/screen
/bin/zsh <--
/usr/bin/zsh <--
Agora, a internet sugere que eu use a de /usr/bin/ .
Minha pergunta é: por quê? Qual é a diferença entre estes dois e porque é que o bash, por exemplo, só é instalado em um caminho ( /bin/bash )?
O conteúdo de /etc/shells é mais ou menos estático e não tem nada a ver com a presença de shells específicos instalados em um sistema.
O fato de haver duas entradas em seu /etc/shells significa apenas que, se um usuário tiver /bin/zsh ou /usr/bin/zsh especificado como seu shell em /etc/passwd , ambos serão considerados "válidos" por daemons que consultam /etc/shells (por exemplo, a maioria dos daemons FTP).
Para ver o primeiro zsh disponível em seu caminho ($ PATH), você pode usar o comando como:
which zsh
Ou whereis, que exibe mais informações (os arquivos binários, de origem e de manual para um comando):
whereis zsh
Quando existe /bin/zsh , a existência redundante de /usr/bin/zsh tem principalmente o propósito de portabilidade no sentido de que você não precisa editar cada e qualquer linha de shebang dos scripts, que, ao usar zsh , provavelmente abordará /usr/bin/zsh .
zsh não é considerado um software standard , mas muitas e cada vez mais pessoas o estão usando, mesmo administradores de sistemas hardcore. E é por isso que mais distribuições tendem a colocá-lo em /bin/zsh também.
Para chegar ao ponto: não é um problema de zsh , mas um recurso que deve garantir a inicialização de um sistema Linux (ou historicamente, Unix) em um estado definido.
/bin é definido para residir no sistema de arquivos raiz, enquanto /usr/bin não é.
Para o último (entre outros), as opções incluem tê-lo em outro disco (partição) ou mesmo em outra máquina e montado via NFS ou outros meios de rede.
Portanto, ao inicializar um sistema sem suporte de rede, ou no caso de a rede cair acidentalmente, ou quando um disco trava ou um sistema de arquivos está corrompido, ou apenas inicializando no modo de usuário único sem montar nada, os arquivos em /bin ainda estão acessíveis.
O mesmo se aplica a /lib e /usr/lib : na verdade, qualquer coisa além de /usr é considerada não vital para o sistema básico (também o X11 é geralmente encontrado em algum lugar na ramificação /usr . a razão pela qual o $ HOME do root não é /home/root , já que /home também é considerado como não residindo no sistema de arquivos raiz.
E se o disco do sistema falhou? Ou o sistema de arquivos raiz está corrompido? Bem, então as chances são de que você não pode nem carregar o kernel ...
Muitos dos itens acima não são muito críticos para os sistemas atuais. Os sistemas de arquivos /usr/* montados pelo NFS são desnecessários, pois o espaço em disco é barato e está disponível em grandes quantidades.
Até mesmo as imagens do SO são instaladas em um sistema de arquivos /boot separado em muitas instalações, de modo que carregar o kernel não garante a montagem do sistema de arquivos raiz, mas para isso temos initrd nos dias de hoje que mantém um sistema de arquivos raiz inicial para a inicialização do kernel (no qual, na verdade, zsh estará ausente na maioria dos casos).
Também é prática comum ter um sistema de arquivos raiz grande que inclua a ramificação /usr , que possui algumas vantagens ao clonar instalações.
Assim, as considerações tradicionais que levaram à distinção de /bin e /usr/bin (e similares) estão um pouco desatualizadas, mas ainda são implementadas em sistemas recentes.
(isso foi mais um aparte, mas estes são os fatos)
Por razões de compatibilidade. Alguns scripts usam / usr / bin outros usam / bin. Diversas distros desejam mover tudo para / usr / bin, pois não há mais sentido em ter / sbin e / bin. Uma das exceções é bash, já que #!/bin/bash tem sido usado em inúmeros scripts nas últimas décadas, então fornecer / bin / bash para compatibilidade, com um symlink, é uma boa solução por enquanto.
eles podem ser os mesmos (verificar tamanhos de arquivo com ls -l) ou / bin / zsh pode ser uma versão vinculada estática
no meu debian jessie booth são os mesmos, mas eu poderia jogar com update-alternatives para fazer / bin / sh um link para / bin / zsh-static
no caso do meu sistema estar sem alguma dependência do zsh link eu seria capaz de logar se o meu shell é / bin / zsh (se ele estiver ligado a / bin / zsh-static)
esta prática é a norma em sistemas solaris, onde o / bin / ksh é uma versão leve do shell korn, onde a versão pesada de todos os recursos reside em / usr / bin / ksh
/ usr / bin precede / bin / no caminho, por isso, se você não especificar qual deles você deseja obter o melhor shell por padrão
Tags zsh