Por que o cd não é um arquivo em / bin? [duplicado]

6

Eu notei que todos os outros utilitários comumente usados, como ls, cp, rm , etc., são arquivos em / bin - mas cd não é. Nem está em nenhum outro diretório binários (por exemplo, /usr/bin, /bin, /sbin etc.).

Por que esse é o caso?

    
por amphibient 22.12.2012 / 05:31

2 respostas

7

cd é um shell embutido . Então é parte do próprio shell, não um executável separado.

Existem basicamente duas classes de builtin.

  • Particulares especiais estão intimamente ligados ao shell, e não podem ser implementados independentemente ou não porque isso não faria sentido funcional (eles são principalmente relacionados ao controle de shell). Eles são chamados de "especiais" porque têm uma semântica específica de tratamento de erros e atribuição de variáveis .
  • Os builtins regulares são normalmente implementados no shell por motivos de desempenho, porque eles manipulam internos do shell ( por exemplo, cd ) ou porque são tecnicamente mais fáceis. Em alguns casos, um builtin regular também pode existir em forma não interna. Um exemplo do último caso é echo , que é implementado em todos os shell modernos, mas também existe, principalmente por razões históricas, como /bin/echo .

Um motivo adicional para a criação de funções críticas é que ele garante que a funcionalidade principal continue acessível, mesmo que algo catastrófico ocorra em seu sistema. Por exemplo, isso pode ser importante se as bibliotecas compartilhadas ficarem corrompidas ou inacessíveis, se você perder o acesso a /bin ou /sbin ou se o sistema se tornar limitado por recursos de uma maneira que não permita a execução de outros executáveis.

    
por 22.12.2012 / 05:33
3

Alguns recursos do histórico do Unix dizem que o comando do foi externo em algum período (bastante antigo) de desenvolvimento do Unix. Este foi um comando especial que conseguiu modificar o diretório atual parent's .

Você pode ver os rudimentos desse estado histórico no fato de que o Solaris tem / usr / bin / cd como um comando real, além dos recursos internos do shell. Mas não tenho certeza se faz algo real nos sistemas atuais.

Sendo este como um comando externo, foi uma solução temporária que foi exterminada assim que os desenvolvedores do Unix tornaram-se capazes de ter shell embutidos. É muito caro ter um comando inteiro (que deve ter seu próprio processo, ser carregado a partir do disco, etc.) no lugar onde a simples chamada do sistema é suficiente. Então, tornou-se um builtin e, desde então, não mudou seu estado nunca.

Poder-se-ia criar um shell onde praticamente qualquer comando se torna construído; este é apenas um tipo de compromisso de design. Por exemplo, cp mencionado aqui poderia ser um bom candidato para isso; e tal build-in foi implementado em alguns shells para o MS-DOS. Mas, no Unix, a criação e o início de processos são mais baratos, e não há necessidade de inventar funcionalmente internamente, a menos que não possa ser implementado a partir de outro processo. Isso inclui cd , ulimit , saída , manipulações de variáveis, comandos de fluxo de controle ( se , para , while , etc.) e assim por diante.

    
por 22.12.2012 / 07:04