Qual é o objetivo de sh estar ligado ao traço?

18

Eu estou querendo saber qual é o ponto em que sh está simbolicamente vinculado a dash ? Eu entendo que dash é supostamente mais rápido que bash , mas não tenho certeza do motivo pelo qual o% original co_de% shell não está presente em sh .

Ou se alguma coisa não está sh vinculada a sh ?

    
por NerdOfCode 14.11.2017 / 23:20

4 respostas

47

A resposta curta para "por que o sh shell original não está presente em sh " é que não há sh original.

Bem, ok, existe: é o shell Thompson . A versão 1 tinha alguns dos recursos que conhecemos hoje, em especial o redirecionamento e os canais (leia o artigo de Dennis Ritchie sobre início do histórico do Unix ). Versões posteriores adicionaram recursos como execução em segundo plano com & , globbing (implementado com um programa externo ), e algumas formas de citar, mas não possuía variáveis ou estruturas de controle aninhadas. Condicionais e loops foram fornecidos por meio de programas externos if (que recebeu uma condição e um comando como argumentos) e < href="https://etsh.io/man/goto.1.txt"> goto (que funcionava alterando a posição do arquivo de seu pai no arquivo de script).

Em 1979, em Unix V7 , o shell Thompson foi substituído como /bin/sh pelo Bourne shell . A primeira versão já tinha muitos dos recursos que estão presentes hoje em dia e versões subsequentes introduzidas muito mais . Alguns anos mais tarde, o shell Korn entrou em cena, com um crescente conjunto de recursos; muitas variantes do Unix o instalaram sob o nome ksh .

Em 1992, POSIX codificou um conjunto mínimo de recursos de sh que era basicamente Bourne e algumas outras coisas. Qualquer sistema que se chamava “Unix” tinha que implementar pelo menos esses recursos. Os sistemas comerciais Unix geralmente usavam o ksh como o POSIX sh, mas alguns (por exemplo, OSF / 1 ) tinham seus próprio.

Nem o shell Bourne nem o shell Korn eram open source até muito recentemente, então quando o mundo Linux começou a se formar em meados dos anos 90, eles não estavam disponíveis. /bin/sh tinha que ser outra coisa. A maioria das distribuições Linux foi para bash , uma shell da Projeto GNU que tendia a ser entre Bourne e Korn em termos de recursos de script, e muito melhor do que o uso interativo. A única alternativa viável foi o pdksh (“shell Korn de domínio público”), um livre (agora descontinuado, mas vivendo como mksh , que é ativamente desenvolvido ), mas não me lembro de uma distribuição Linux usando pdksh como /bin/sh , não sei porque, eu acho, porque as distribuições Linux eram sempre distribuições GNU / Linux, basicamente distribuindo versões GNU de qualquer ferramenta para a qual existisse uma versão GNU.

Também houve várias implementações de código-fonte aberto de sh chamadas "ash", mais notavelmente a concha de Almquist , mas eles eram muito incompletos, faltando alguns recursos POSIX que as pessoas queriam usar. Um programador que era mantenedor do Debian, Herbert Xu , estendeu as cinzas para torná-lo compatível com POSIX. Eventualmente, sua versão foi renomeada para dash, e houve algum esforço para torná-la /bin/sh no Debian em vez de bash. O Ubuntu começou antes do Debian começar a tratar sistematicamente os bashisms (o uso de funcionalidades específicas do bash em #!/bin/sh scripts) como bugs . Ambos trocaram um (Ubuntu 6.10), Debian somente em 2009 ( era um objetivo para o lenny mas a mudança só foi feita após o lançamento do lenny, ou seja, no squeeze)).

Um importante motivo para usar o dash como em vez de bash , pois /bin/sh é que ele é significativamente mais rápido. Isso foi especialmente importante para o Ubuntu, que se esforçou para manter os tempos de inicialização curtos desde o início. Dash também tende a usar menos memória do que o bash, o que é um pouco importante para os scripts de wrapper que ficam por perto apenas para fazer um pouco de limpeza quando o programa subjacente sai. Outro benefício do dash é que ele só depende da libc (a biblioteca principal do sistema), enquanto o bash também depende de bibliotecas de suporte ao terminal (ele não pode ser iniciado sem elas, nem mesmo para executar um script); Isso significa que o traço tem uma chance melhor de continuar trabalhando em um sistema quebrado.

Em algum ponto durante o século 21, o shell Korn foi open source, e versões open source do shell Bourne apareceram (versões antigas, porque o desenvolvimento havia cessado anos antes). Mas dash e bash estavam muito firmemente entrincheirados no mundo Linux para que eles obtivessem alguma aceitação, especialmente o shell Bourne, já que seu valor hoje é apenas histórico. Dash deslocado bash porque tinha benefícios claros, mas nenhum dos outros contendores tem qualquer vantagem decisiva como /bin/sh .

    
por Gilles 15.11.2017 / 00:48
18

A conformidade com velocidade e POSIX (em outras palavras, portabilidade) são os principais fatores. Lembre-se que /bin/sh é destinado a scripts de sistema, que podem ou não ter vindo de versões mais antigas do Ubuntu e / ou outros sistemas.

Claro, recursos brilhantes de bash são legais para usar para nós usuários, mas quando se trata de executar algo no ambiente onde você tem que gerenciar vários servidores / sistemas diferentes - ter shell compatível com POSIX faz muita diferença. Especialmente, se você é um novo administrador de sistema e um ambiente herdado com muitos scripts.

Quanto ao motivo pelo qual o shell Bourne original não está presente, é simples - é um produto proprietário originalmente pertencente à AT & T Bell Labs.

Além disso, há uma explicação explícita no wiki do Ubuntu sobre isso:

  

Por que essa mudança foi feita?   O principal motivo para mudar o shell padrão foi a eficiência. O bash é um excelente shell completo adequado para uso interativo; na verdade, ainda é o shell de login padrão. No entanto, é bastante grande e lento para iniciar e operar por comparação com o traço. Um grande número de instâncias de shell é iniciado como parte do processo de inicialização do Ubuntu. Em vez de alterar cada um deles individualmente para executar explicitamente em / bin / dash, uma mudança que exigiria uma manutenção contínua significativa e que poderia regredir se não recebesse muita atenção, a equipe de desenvolvimento principal do Ubuntu achou que era melhor simplesmente mudar o shell padrão. As melhorias na velocidade de inicialização do Ubuntu 6.10 foram frequentemente atribuídas incorretamente ao Upstart, que é uma boa plataforma para desenvolvimento futuro do sistema init, mas no Ubuntu 6.10 foi executado principalmente no modo de compatibilidade do System V com apenas pequenas mudanças comportamentais. Essas melhorias foram em grande parte devido à mudança / bin / sh.

E aqui está uma nota sobre portabilidade:

  

O manual de políticas Debian tem mandado que "shell scripts especificando '/ bin / sh' como intérprete deve usar apenas recursos POSIX"; Na verdade, este requisito está em vigor desde muito antes do início do projeto Ubuntu. Além disso, quaisquer scripts de shell que esperassem ser portáveis para outros sistemas Unix, como os BSDs ou Solaris, já cumpriam esse requisito. Assim, achamos que o impacto de compatibilidade dessa mudança seria mínimo.

Veja link

    
por Sergiy Kolodyazhnyy 15.11.2017 / 00:19
8

Nas distribuições GNU / Linux, o "original /bin/sh " é realmente Bash.

O GNU queria um shell parecido com o Bourne que estivesse sob a GPL, e é por isso que eles escolheram o Bash para seu /bin/sh , em vez do Bourne, que não era licenciado pela GPL. As distribuições Linux modernas herdaram essa decisão a ponto de se tornar um padrão de fato para /bin/sh ser Bash. O shell Bourne original ("sh") foi usado em outros Unixes não-Linux, até recentemente, como o Solaris 10, mas nunca foi um elemento essencial nas distribuições Linux.

Mudar /bin/sh de bash para traço foi uma decisão Debian (herdada do Ubuntu) motivada em grande parte pela velocidade - surgiu em um momento em que eles se empenharam em melhorar a velocidade de inicialização e uma grande parte do tempo de CPU da inicialização no momento consistente de executar scripts init.

O Bash continua a ser usado como o shell interativo / de login padrão para os usuários, mas Dash é o que está em /bin/sh e aquele que é executado para scripts do sistema, como scripts init.

O Dash é muito rápido, mas também é muito próximo do POSIX-compatível - um padrão que está alinhado de perto com o shell Bourne. Então, de certa forma, ao mudar de Bash para Dash, estamos voltando para uma concha mais alinhada com Bourne.

    
por thomasrutter 15.11.2017 / 00:30
0

/bin/sh está vinculado a /bin/dash pelo que acredito serem razões de compatibilidade. Muitos scripts simplesmente começam com

#!/bin/sh

então, mudando para dash e não fazendo um link simbólico, muitos scripts não seriam executados adequadamente (ou de forma alguma) se /bin/sh não existisse.

A alteração foi feita de bash para dash porque, de acordo com o link :

  

O principal motivo para mudar o shell padrão foi a eficiência. O bash é um excelente shell completo adequado para uso interativo; na verdade, ainda é o shell de login padrão. No entanto, é bastante grande e lento para iniciar e operar por comparação com o traço. Um grande número de instâncias de shell é iniciado como parte do processo de inicialização do Ubuntu. Em vez de alterar cada um deles individualmente para executar explicitamente em / bin / dash, uma mudança que exigiria uma manutenção contínua significativa e que poderia regredir se não recebesse muita atenção, a equipe de desenvolvimento principal do Ubuntu achou que era melhor simplesmente mudar o shell padrão.

sh não está vinculado a bash , porque

  

O manual de políticas Debian mandou há muito tempo que "scripts de shell especificando '/ bin / sh' como intérprete devem usar apenas recursos POSIX"

Se você quiser usar bash como /bin/sh :

  

Se os problemas forem mais generalizados e você quiser alterar o shell padrão do sistema, você pode instruir o sistema de gerenciamento de pacotes a parar de instalar o dash como / bin / sh:

sudo dpkg-reconfigure dash

Existem alguns recursos que o dash fornece que o bash não possui, como:

  

existe até uma chance externa de haver alguns scripts que agora dependem de algum recurso do traço que o bash não fornece!

    
por NerdOfLinux 14.11.2017 / 23:23