Por que ninguém usa o verdadeiro shell Bourne como / bin / sh?

55

Tenho notado que basicamente nenhum sistema com o qual eu já trabalhei tem /bin/sh como um executável real. É sempre um symlink para dash , bash no modo POSIX, ou algo similar.

Por quê? Quais são as desvantagens de usar o verdadeiro% original/bin/sh? (Licença? Licenciamento?)

    
por strugee 05.11.2013 / 04:34

5 respostas

38

Eu acho que falta de recursos - nenhum histórico de comandos, nenhum redirecionamento sofisticado, nenhuma edição de linha de comando. O BSD introduziu csh da shell C por essas razões. Outro fator é que o Genuine Bourne Shell estava disponível recentemente apenas no formato open source . A menos que você tenha licenciado, você não poderia distribuí-lo. Isso o colocava fora de alcance para distribuições gratuitas e tornava ideologicamente intragável para outras distros e * BSDs.

Mas o código está disponível agora. Você pode dar uma olhada, compilar, dar uma olhada.

    
por 05.11.2013 / 05:10
23

A afirmação na sua pergunta está incorreta. O Solaris até a versão 10 está fornecendo o verdadeiro shell legado Bourne como /bin/sh . Isso foi feito para não quebrar a compatibilidade com scripts antigos que podem falhar com um shell diferente. Esta escolha foi muito frustrante, apesar disso.

A maioria, se não, todas as versões restantes Unix e Unix, incluindo Solaris 11, fornecem um shell compatível com POSIX como /bin/sh porque POSIX ordena o comando sh para iniciar um shell POSIX, não o shell Bourne legado que não é compatível. /bin/sh geralmente é:

  • ksh88 ou ksh93 nas implementações comerciais do Unix
  • um bash on OS/X modificado (embora tenha sido zsh )
  • um derivado ash ou pdksh em outro BSDs
  • bash ou dash nas distribuições do Gnu / Linux.

Não é necessariamente um link, mas pode ser um verdadeiro executável em muitos sistemas, exceto o Gnu / Linux.

Curiosamente, apesar do que afirma a resposta mais votada à sua pergunta, não é a falta de recursos que levam os desenvolvedores de distribuição a instalar algo diferente do shell Bourne legado em /bin/sh , mas o desejo de ser o mais compatível com POSIX , ou seja, para se comportar como um Unix como o SO. O fato do shell POSIX ter mais recursos do que o shell Bourne legado é apenas um efeito colateral desse objetivo padrão de conformidade.

Também é um fato que alguns shells, notavelmente bash , se comportam de maneira diferente quando chamados de sh , e isso remove principalmente recursos do shell, e não o contrário.

    
por 05.11.2013 / 08:04
16

Até onde eu sei, o shell Bourne original não poderia ser usado pelos BSDs e pelo projeto GNU, por causa de sua licença.

Naquela época, o Unix original não tinha licença e o projeto GNU precisava de um shell que estivesse sob a GPL, então eles usaram o bash.

O mesmo vale para o BSD4, o pai de todos os BSDs. Graças ao processo AT & T, eles precisaram reescrever todas as fontes do Unix original, incluindo o shell Bourne.

In the traditional BSD line, the Bourne shell was shipped until 4.3BSD-Reno (but not anymore with Net/2 and the following 4.4BSDs). For license reasons it was then substituted with the bourne-compatible, svr4-like sh by Kenneth Almquist (often called ash).

Do FreeBSDs man sh

A sh command, the Thompson shell, appeared in Version 1 AT&T UNIX. It was superseded in Version 7 AT&T UNIX by the Bourne shell, which inherited the name sh.

This version of sh was rewritten in 1989 under the BSD license after the Bourne shell from AT&T System V Release 4 UNIX

Assim, ambos os projetos foram forçados a não usar o shell Bourne e se contentar com um verdadeiro shell de código aberto.

    
por 05.11.2013 / 07:33
7

Houve outros problemas. O Bourne Shell usou sbrk () de malloc () e isso não fez muito portátil.

Depois que a Bourne Shell se tornou OpenSource via OpenSolaris, eu criei uma versão portáteis hafway e, posteriormente, uma versão realmente portátil, substituindo sbrk () por malloc () com a ajuda de Geoff Collyer (a mesma pessoa que ajudou a evitar sbrk () na Korn Shell).

O motivo inicial, porque eu fiz uma versão portátil da Bourne Shell é que eu gostei de fazer o Editor de História que escrevi para o meu "bsh" entre 1982 e 1984 disponíveis na Bourne Shell também. Enquanto isso, eu portei mais das características únicas que escrevi para "bsh" no Bourne Shell.

Isto é entre outros:

  • Compila e trabalha em quase todos os lugares, incluindo o Cygwin (quase 2x mais rápido que o bash)
  • O editor de histórico com um buffer de anel LRU
  • TERMCAP incorporado
  • Aliases avançados (aliases persistentes globais, aliases locais, ....) e junto com o "dosh" embutido, a Bourne Shell é a apenas a implementação da Bourne Shell que permite a parametrização aliases.
  • Suporte para editar aliases complexos no editor de histórico no modo raw.
  • Acesse todos os 32 bits do código de saída (2) por meio das variáveis .sh. *.
  • tempo automatizado avançado com resolução de 6 dígitos
  • pushd / popd / dirs
  • incorporado "localizar"
  • Tubulação de stderr
  • Usando vfork () para melhor desempenho.
  • finalmente consertamos todos os bugs documentados do Bourne Shell SVr4, por exemplo. suspender sempre funciona no modo de controle de trabalho. ...

A página de manual online está em:    link As fontes são parte da caixa de ferramentas do schily em:

link

Eu recomendo usar: link ou uma versão mais recente.

P.S. Estou interessado em feedback

    
por 18.08.2015 / 13:48
4

Ele está vinculado a shells que fornecem 100% Compatibilidade retroativa . Você não perde nada que o shell original tenha, mas ganha mais recursos em cima dele. Não há desvantagem, então por que perder os novos recursos? Esta é a mesma razão pela qual o /bin/vi está normalmente ligado ao vim .

    
por 05.11.2013 / 16:02