Por que bash é o shell padrão na maioria dos sistemas operacionais?

Question

Por que o bash é o shell padrão na maioria dos sistemas operacionais (Ubuntu, Fedora, OSX, etc.)? Por que muitos usuários avançados usam principalmente o zsh? Se é assim tão bom, por que não é o padrão?

Eu uso os dois Não vejo diferença para todas as minhas tarefas serem simples:)

    

Answer 1

Eu fiz algumas leituras sobre isso e a conclusão parece ser que é o shell padrão do GNU (usado pela maioria dos OS), e portanto vem simplesmente empacotado como parte do GNU, enquanto também tem 20 anos de desenvolvimento por trás, tornando-o estável e bem arredondado, é simplesmente o melhor em todos os aspectos, atendendo às necessidades de todos, exceto dos usuários mais avançados. p>

Para mais, leia Por que o bash é padrão no Linux? (a mesma pergunta no Unix e no Linux).

Só para adicionar um pouco mais a isso, existem muitos outros shells para testar, se você estiver interessado, aqui estão alguns desta resposta :

• Zsh has more advanced interactive facilities, but a few quirks when it comes to scripting (less so now than back in the days). In the early to mid-1990s when Linux was in its infancy, zsh was virtually unknown.

• Ksh was the de facto standard on commercial unices since the mid-1980s, but it was proprietary software until 2000, so not an option on Linux. Also, ksh had subpar command line editing capabilities, compared with bash.

• Pdksh, a free clone of ksh, would have been an option, but it was not well-known and had poor command line edition capabilities. (Pdksh is no longer a very active project, even though it's still used in some BSDs, now that ATT ksh is free.)

• Some distributions install an ash variant as /bin/sh. Ash (by which I mean any of the loose family of shells called ash) is designed to be small and fast, with no interactive features (it's only for editing scripts). The ash revival is relatively recent; in the 1990s the existing variants lacked a lot of features.

• Tcsh was the most advanced interactive shell until zsh came along, but it's incompatible with sh and not so good with scripting.

    

Answer 2

A Bourne Shell ( sh no passado) do ramo AT & T do Unix foi aprimorada e substituída pelo Korn Shell, ksh . O ksh também saiu do AT & T Bell Labs e não era GPL (a versão atual é Eclipse Public License). O C-shell, csh saiu da versão Berkeley do Unix e também não era GPL (licença BSD) e também usou sintaxe diferente de sh. O Z-shell, zsh é uma melhoria na sh, mas não na GPL (licença do tipo MIT). Bash foi uma melhoria em sh, usou o GPL e do GNU. Apenas na licença, Bash provavelmente teria sido a escolha para um sistema operacional GPL. Particularmente com uma casca sendo uma parte essencial de uma distro.

Mas o Bash também era um projeto GNU, dando a ele um desenvolvimento mais ativo e facilitando as contribuições do que um produto herdado do Berkeley Unix ou do AT & T Unix. Um caso muito bom poderia ser feito de que o zsh é e tem sido um shell melhor que o Bash, mas não o suficiente para superar sua licença diferente e status de projeto não-GNU.

Quando as distros do Linux apareceram pela primeira vez e escolheram seu shell padrão (do início até meados dos anos 90), não havia github (2008) ou mesmo SourceForge (1999). Nesse ponto, acho que os projetos GNU tiveram uma vantagem real sobre os projetos não-GNU em serem notados e desenhar e incluir novos desenvolvedores. Então, distros podem olhar melhor para o Z-shell, mas também esperam que o Bash esteja recebendo um bom suporte e manutenção, além de ter mais recursos adicionados, permitindo que ele alcance até o zsh.

Agora que Bash teve anos de status padrão, tornou-se um padrão de fato, com livros escritos sobre isso. Há um um livro que abrange tanto o Bash quanto o Z-shell , mas nenhum livro que o cobre exclusivamente, enquanto há vários que o fazem para Bash.

E, neste ponto, se as distribuições alterassem o padrão para atualizações de um sistema existente, elas iriam quebrar configurações, já que alguns arquivos de inicialização têm nomes diferentes (por exemplo, .bashrc versus .zshrc) e o conteúdo dos arquivos pode ter sintaxe incompatível. Então, eles relutariam em fazer isso, deixando novos downloads para ter zsh como padrão e upgrades para ter bash. Dois padrões diferentes para a mesma distro são algo que eles provavelmente não querem ter suporte e os usuários / empresas também não querem lidar com isso.

    

Answer 3

As linguagens shell do Unix são todas feias. Alguns particularmente ( csh ), alguns talvez um pouco menos ( ksh ? Eu não sei realmente), mas realmente quando se trata de aspectos como legibilidade e rigidez para grandes projetos, nenhum deles pode se aproximar bem. projetou linguagens de propósito geral, como Python, C # ou Haskell. Então, quando você quer algo sólido, você nunca escolherá nenhum dos sabores de casca.

Você os escolhe quando quer rapidamente fazer coisas simples. Para isso, você precisa:

• Sintaxe concisa e consistência suficiente para que você possa memorizá-la (é difícil procurar operadores de taquigrafia). É muito importante se o seu shell estiver instalado em todos os lugares, porque você realmente prefere não memorizar mais do que um desses monstros do kludge.
• Bons recursos interativos, para que você possa invadir o terminal e fazer com que as coisas funcionem sem precisar alternar entre vários arquivos de script.
• A capacidade de pegar qualquer trecho de script de qualquer lugar e fazê-lo funcionar. sh compatibilidade é uma grande vantagem aqui, e mais uma vez, quanto mais popular, melhor.

Então, você vê, a popularidade é um ponto maior nessas linguagens shell do que para linguagens de propósito geral. Portanto, mesmo que ksh seja um pouco “melhor” como uma linguagem em si, não há realmente tanta vantagem em usá-la se bash é apenas um pouco mais popular (o que era, no setor relevante, foi escolhido pela primeira vez como padrão para o GNU).

As pessoas que fazem a troca são deliberadas sobre isso e têm experiência suficiente para lidar facilmente com a mudança para sua concha favorita. OTOH, um novato que é forçado a trabalhar com um shell menos popular, será rapidamente confundido se pedir algo à Internet e não funcionar. Assim, qualquer distro que não seja destinada apenas a veteranos do Unix corre algum risco se fizer algo diferente de bash do padrão, um passo do qual relativamente poucas pessoas se beneficiariam (e apenas um pouco).

    

Answer 4

1. Estava lá quando foi necessário
2. A atenção é suficiente para que os usuários iniciantes passem uma semana personalizando o prompt deles.
3. Os casos de uso comuns são bons o suficiente (o mais comum é iniciar um único comando)
4. Onde não é bom o suficiente perl, python e lua podem ocupar a folga.
5. perl faz um terrível shell interativo
6. embora fish, ksh ou zsh possam, teoricamente, ser um shell melhor, não há uma melhora suficiente para eu me incomodar quando o perl funciona tão bem ou a portabilidade é um problema, então estou direcionando o dash mesmo assim.

Answer 5

"Massa crítica" é a resposta principal, IMO. Bash não é apenas para o trabalho de linha de comando, é para scripts e há um grande número enorme de scripts Bash por aí. Não importa o quanto melhor uma alternativa seja agora para interação, a necessidade de poder apenas "plug and play" desses scripts supera tais vantagens. Como tal, o único shell que pode realisticamente desbancar o Bash agora é aquele que é completamente compatível com versões anteriores e o candidato mais provável para isso é ... a próxima versão do Bash.