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

55

Percebi que basicamente nenhum sistema com o qual trabalhei tem /bin/shum executável real. É sempre um link simbólico para dash, bashno modo POSIX, ou algo semelhante.

Por quê? Quais são as desvantagens de usar o verdadeiro, original /bin/sh? (Velocidade? Licenciamento?)

shell history dash

— strugee
fonte

3

Você já usou o Linux, certo? Eu só vi "sh as symlink" no Linux.

— Greg Hewgill

@GregHewgill As versões recentes do Solaris não estão shvinculadas ksh?

— Gilles 'SO- stop be evil'

11

@ Gilles de acordo com uma das respostas, sim, desde que o Solaris 11. está vinculado ksh.

— strugee

11

@GregHewgill Eu também usei Darwin, que tem o link para o bashIIRC.

— strugee

6

O que você quer dizer com original / bin / sh ? O shell Thomson do Unix V1? O shell Bourne do Unix V7 que não tinha funções, não comenta ...? O do SysIII, SysV, Solaris, HP / UX, a reimplementação de cinzas nos BSDs? Atualmente, shé baseado em um padrão, o que significa que podemos ter várias implementações que se comportarão de maneira clara e especificada, desde que você use a sintaxe padrão em seu script.

— Stéphane Chazelas

38

Eu acho que falta de recursos - sem histórico de comandos, sem redirecionamento sofisticado, sem edição de linha de comando. O BSD introduziu csho shell C por esses motivos. Outro fator é que o Bourne Shell original estava disponível apenas recentemente em código aberto . A menos que você o licencie, você não poderá distribuí-lo. Isso o colocou fora do alcance de distribuições gratuitas e o tornou ideologicamente desagradável para outras distribuições e * BSDs.

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

— Bruce Ediger
fonte

50

E, em seguida, volte rapidamente para o que estava usando antes.

— Ignacio Vazquez-Abrams,

24

@strugee "" falta de recursos "- por que isso seria um problema?" Sim, bom ponto ... por que os programadores usam coisas inúteis como assembly / C / linguagens de alto nível, quando qualquer coisa que você pode fazer com eles, você já pode escrever linguagem de máquina diretamente? O fato é que: características = aumento na velocidade de desenvolvimento + aumento da capacidade de manutenção = menor custo = melhor O uso shé exatamente igual ao uso, bashexceto pelo fato de ser: mais lento, os programas são mais longos e mais difíceis de manter.

— Bakuriu

10

Não é realmente a falta de recursos, mas o fato do POSIX exigir que o shcomando execute um shell compatível com POSIX, o que o shell Bourne herdado não é. Embora o POSIX não exija shestar /bin/sh, esse é o diretório mais lógico para ele.

— Jlliagre

4

O histórico de comandos do @Bakuriu e a edição da linha de comandos são coisas que você realmente não precisaria para um script.

— strugee

4

@ strugee Essas não são as únicas diferenças. Por exemplo sh, não possui expansão de til e braçadeira, alguns componentes internos estão ausentes (por exemplo , pushde popd, select) sem expansão aritmética. Muitas variáveis estão ausentes, por exemplo PIPESTATUS.

— Bakuriu 6/11/2013

23

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

A maioria, se não todas as versões restantes do Unix e do Unix, incluindo o Solaris 11, fornece um shell compatível com POSIX, /bin/shporque o POSIX exige o shcomando para iniciar um shell POSIX, não o shell Bourne herdado que não é compatível. /bin/shé geralmente :

ksh88ou ksh93nas implementações comerciais do Unix
um modificado bashem OS/X(embora costumava ser zsh)
um ashou pdkshderivado em outroBSDs
bashou dashem distribuições Gnu / Linux.

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

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

Também é um fato que algumas conchas bashse comportam de maneira diferente quando chamadas sh, e isso remove principalmente os recursos do shell, e não o contrário.

— jlliagre
fonte

16

Até onde eu sei, o shell Bourne original não pôde 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, para que eles usassem o bash.

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

Na linha BSD tradicional, o shell Bourne foi enviado até 4.3BSD-Reno (mas não mais com Net / 2 e os 4.4BSDs a seguir). Por motivos de licença, ele foi substituído por Kenneth Almquist (sh, compatível com bourne), semelhante a svr4 (freqüentemente chamado de ash).

Do FreeBSDs man sh

Um comando sh, o shell Thompson, apareceu na versão 1 da AT&T UNIX. Foi substituído na Versão 7 AT&T UNIX pelo shell Bourne, que herdou o nome sh.

Esta versão do sh foi reescrita em 1989 sob a licença BSD após o shell Bourne do AT&T System V Release 4 UNIX

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

— Raphael Ahrens
fonte

7

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

Depois que o Bourne Shell se tornou OpenSource via OpenSolaris, criei uma versão portátil 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 () no Korn Shell).

A razão inicial pela qual fiz uma versão portátil do Bourne Shell é que gostei de disponibilizar o Editor de História que escrevi para o meu "bsh" entre 1982 e 1984 no Bourne Shell. Enquanto isso, eu portava a maioria das características únicas que escrevi para "bsh" para o Bourne Shell.

Isto é entre outros:

Compila e funciona em quase todos os lugares, incluindo Cygwin (quase duas vezes mais rápido que o bash)
O editor de histórico com um buffer de anel LRU
TERMCAP embutido
Aliases avançados (aliases persistentes globais, aliases locais, ....) e, juntamente com o "dosh" interno, o Bourne Shell é a única implementação semelhante do Bourne Shell que permite aliases parametrizáveis.
Suporte para editar aliases complexos no editor de histórico no modo bruto.
Acesse todos os 32 bits do código de saída (2) por meio de variáveis .sh. *.
cronometragem automatizada avançada com resolução de 6 dígitos
pushd / popd / dirs
builtin "encontrar"
Tubo de stderr
Usando vfork () para obter melhor desempenho.
finalmente corrigimos todos os bugs documentados do SVr4 Bourne Shell, por exemplo, a suspensão sempre funciona no modo de controle de tarefas. ...

A página do manual on-line está em: http://schillix.sourceforge.net/man/man1/bosh.1.html As fontes fazem parte da caixa de ferramentas inteligente em:

https://sourceforge.net/projects/schilytools/files/

Eu recomendo usar: http://sourceforge.net/projects/schilytools/files/schily-2015-08-18.tar.bz2 ou uma versão mais recente.

PS Estou interessado em feedback

— esperto
fonte

Oi Joerg. Por que portá-los para o shell Bourne, em vez de um shell que já havia sido POSIXificado como algum BSD sh ou pdksh?

— Stéphane Chazelas

A portabilidade da Bourne Shell foi um desafio, pois não usa o stdio. Esse foi um desafio semelhante ao pegar a fonte csh original e compilá-la, substituindo a impressão não-stdio gravada no VAX assembler. Mas eu já adicionei muitos recursos POSIX mais recentes ao Bourne Shell e gosto de ficar com o Bourne Shell no SchilliX para permitir que ele inicialize com / anr / usr em sistemas de arquivos separados, o que não é possível com o Korn Shell.

— Schily

Observe também que eu queria verificar se a velocidade do ksh é causada pelo uso do vfork (). Agora que converti o Bourne Shell para usar o vfork () é exatamente tão rápido quanto as versões recentes do ksh. Essa é uma experiência que você só obtém ao iniciar com o código-fonte original do Bourne Shell.

— schily

OK, mas até que você esteja em conformidade com o POSIX, é provável que não atraia muito interesse. Lembro que você perguntou no grupo austin ML sobre as incompatibilidades com o POSIX do shell Bourne, é algo em que você está trabalhando (o que significaria quebrar a compatibilidade com o shell Bourne)? Também as pessoas (pelo menos) consideram a sintaxe do POSIX sh um progresso sobre o shell Bourne. Manter a chamada de shell derivada de Bourne pode ser a impressão errada. E o bimsh (Bourne melhorou (ala vi / vim))?

— Stéphane Chazelas

Meu Bourne Shell já é melhor que o ksh em alguns aspectos, por exemplo, implementando melhores aliases, pushd / popd / dirs e suporte à utilização de recursos com base nos recursos modernos do UNIX, se o que o ksh faz ainda é baseado no SVr2. Como você parece interessado e habilidoso no shell, gostaria de obter idéias sobre o que gostaria de ver a seguir no Bourne Shell depois de ler: schillix.sourceforge.net/man/man1/bosh.1.html Observe que até agora, tenho todo o novo código # ifdef'd e alguns recursos (como tubos stderr) precisam ser ativados via set (1).

— schily

4

Ele está vinculado a shells que fornecem 100% de compatibilidade com versões anteriores . Você não perde nada do que o shell original possui, 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 /bin/vigeralmente está vinculado ao vim .

— JoelFan
fonte

5

A desvantagem é que as pessoas escrevem scripts que funcionam em um único sistema, pensando que o script é compatível quando não é. Certa vez, corrigi quase cem scripts de shell do Gentoo que realmente exigiam bash, mas que chamavam / bin / sh. Todos eles quebraram quando eu mudei / bin / sh para ser dash em vez de bash.

— Zan Lynx

3

"nenhuma desvantagem" - velocidade. por exemplo, bashé muito, muito mais lento quedash

— strugee

@ strugee Se você está procurando melhorias na velocidade da ms em um shell, provavelmente não está usando a ferramenta certa para o trabalho.

— Chris Baixo

11

@ChrisDown define "melhorias na faixa de ms"?

— strugee

2

A sintaxe do POSIX sh não é totalmente compatível com a sintaxe Bourne sh. Por exemplo, IFS=,; rm file1,file2,file3removeria esses 3 arquivos no shell Bourne. Esse recurso (bobo) foi removido no POSIX sh. Existem dezenas de diferenças sutis que podem fazer com que um script escrito para o shell Bourne funcione de maneira diferente com um POSIX sh.

— Stéphane Chazelas