gildot

Topo
Sobre
FAQ
Tópicos
Autores
Preferências
Artigos
Sondagens
Propor artigo


8/3
gildicas
9/30
jobs
10/9
perguntas
10/25
press

 
bash = default shell or bash = best shell ?
Contribuído por scorpio em 01-06-01 16:50
do departamento shells
perguntas Anonimo Cobarde escreve "Uso Linux há relativamente pouco e como "newbie" gostaria que alguem me pudesse explicar qual a diferença (vantagens, desvantagens, utilidade, etc) dos diferentes tipos de shell existentes (bash, csh, ksh, etc)."

Themes dot ORG smi-DEAD ! | MandrakeSoft lança distribuição Linux para Itanium  >

 

gildot Login
Login:

Password:

Referências
  • Linux
  • Mais acerca perguntas
  • Também por scorpio
  • Perguntas
  • Como se pode ter o seu próprio host ?
  • Linux preparado para 'enterprise'?
  • Produtividade: linha de comando vs IDE
  • Sistemas operativos: O que são?
  • linux distribuído nas revistas, sim ou não ?
  • Pergunte ao Gildot: qual o melhor codificador de mp3?
  • staroffice
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    bash vs sh. (Pontos:3, Informativo)
    por leitao em 01-06-01 17:49 GMT (#1)
    (Utilizador Info)
    A regra que eu uso e', para uso interactivo a 'bash' e' a melhor. Para scripting usa a velhinha 'sh'.

        A maioria dos sistemas operativos (os comerciais) nao veem com 'bash', e para desenvolver scripts que correm em todo o lado a 'sh' e' a mais portavel. Em relacao a csh/tcsh e ksh nao gosto muito porque nao sao muito "programaticas" -- nisso a 'sh' e' muito mais generica, embora mais dificil de aprender.

        Cheers,

    -- "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?" -- Steve Elias
    bash vs resto-do-mundo (Pontos:3, Interessante)
    por Anonimo Cobarde em 01-06-01 18:38 GMT (#3)
    Sim, definitivamente a plain sh e' mais portavel.
    Mas... O problema e' que os unixes que penetraram no lerdo-market (leia-se "quase todas as distros de Linux") NAO trazem a sh. Trazem um lindo symlink `a bash. Enquanto tudo o que funciona na sh funciona na bash, o contrario nao e' verdade. A RedHat, por exemplo, brinca muito com expansoes ANSI em scripts com shebang "#!/bin/sh".
    Anyway... Quanto `a ksh, nao me pronuncio. Tive que trabalhar com isso durante 1 ano e pouco, e quase que me embebedei de felicidade quando mataram aquelas AIX.
    (t)csh... Ja me deu para usar como shell (nao para scripts). Nao faz nada que a bash nao faca (pelo contrario). So' muda a sintaxe. E como me habituei a one-liners frequentes para desenrasques, acabei por passar para a bash.
    ash... Ainda bem que isso acabou por desaparecer. Era um pesadelo de seguranca.
    E agora ha uma nova mt gira para recuperar sistemas damaged: sash. Lightweight, de preferencia statically-linked. Tem todos os comandos basicos built-in (ls, mount, rm, etc). Muito gira, testem!
    Re:bash vs resto-do-mundo (Pontos:2, Informativo)
    por jmce em 02-06-01 7:11 GMT (#8)
    (Utilizador Info) http://jmce.artenumerica.org/
    NAO trazer a sh e trazer a bash e' um problema? Normalmente considero o contrario (uma das primeiras coisas que fazia quando chegava a um sistema Unix sem bash era instala-la...).

    Quando a bash e' invocada com 'sh', tem um comportamento ligeiramente diferente, conforme a norma POSIX para a shell.

    Nao ha' grande razao para preferir a sh classica (se e' que existe so' uma) `a bash, excepto se o tamanho da shell se tornar um factor importante (ja' que a bash e' anafadinha) ou a nostalgia apertar...

    Da ksh sei pouco, mas creio ser a mais flexivel em funcionalidade de programacao, nomeadamente com "mappings" (como os dicionarios do Python e as "associative arrays" do Perl). Mas talvez seja sobretudo interessante para os grandes fas de programacao de shell, nestes dias de Perl e Python...

    De todas, penso que para o uso interactivo no dia-a-dia, mesmo para utilizadores principiantes, a bash sera' a mais simpatica, com a tcsh logo atras. Enfim, tao simpaticas quanto uma shell com a heranca historica de todas estas pode ser... :-)

    Re:bash vs sh. (Pontos:2)
    por z0mbi3 em 02-06-01 0:50 GMT (#5)
    (Utilizador Info) http://z0mbi3.sempre.nu
    hum, last time I checked havia um 'ln -s /bin/bash /bin/sh' algures....
    mas como ja nao uso o Linux ha muito tempo nao posso confirmar....
    ZSH (Pontos:2)
    por MavicX em 01-06-01 18:30 GMT (#2)
    (Utilizador Info)
    A minha favorita embora não seja muito conhecida é a ZSH podes encontra-la em www.zsh.org

    Foi das ultimas shells a entrar para o mercado e é muito interactiva alem ser extremante completa ( e complexa ).

    E dizem as más linguas que tem tantas funções que nem o criador sabe para que elas servem.

    Downsize é grande e ocupa muito mais memoria que as outras.
    Sobre a csh... (Pontos:2, Informativo)
    por jmce em 01-06-01 21:55 GMT (#4)
    (Utilizador Info) http://jmce.artenumerica.org/
    Sobre problemas da shell csh e derivadas: "Csh Programming Considered Harmful".
    shells, longo (Pontos:2, Interessante)
    por Anonimo Cobarde em 02-06-01 1:28 GMT (#6)
    bom, respondendo directamente à questao, a bash dificilmente pode ser considerada a melhor shell em absoluto (ate porque isso da sempre origem a varias opinioes difusas), e definitivamente nao é a default shell.

    quanto à sua "bondade", a bash é boa, mas é grande e lenta. o lento chateia sobretudo no uso interactivo (porque em scripts, a nao ser que so se usem builtins, as invocacoes dos progs externos compensam sempre o atraso da shell). o grande chateia em ambos os usos (deixar um "sleep 99&" deixa-me um processo com o tamanho da bash, embora os SOs possam fazer batota para nao gastar realmente tantos recursos).

    quanto ao default, vêm-me à cabeca dois defaults mais comuns: o que é que se da aos users -- aqui depende muito das distro's e/ou sistemas operativos, suponho que nas linuxadas a bash venha como default, na maior parte dos unixes comerciais vem a ksh) -- e em que é que se correm scripts. nesta ultima existem duas respostas: as pessoas com bom senso usam plain old /bin/sh, muitos dos unixes comerciais usam /bin/ksh que sao usualmente implementacoes compativeis com a ksh88, nas linuxadas, tende-se a meter alguns bashismos pelo meio. Ainda existem sistemas que usam o /sbin/sh que é a bourne shell antiga, com mais alguns pozinhos, tb velhinos, mas que nao existiam na original (esses sistemas têm na /bin/sh a original). [ok, afinal nao foram so duas respostas...]

    Resumo: para fazer scripts -- /bin/sh mesmo usando os pozinhos (ver mais abaixo), interactivamente -- escolhe-se a que se gostar mais, e aprende-se todos os truques que ela nos oferece. usar uma shell só para se usarem as teclas do cursor, raramente é uma boa decisao.

    Em relacao as shells em geral, muito resumidamente, a coisa evoluiu assim (+/-): sh -> ksh, csh -> tcsh -> ksh88, bash -> zsh ...

    As datas nao sao muito importantes (a sh apareceu em meados dos anos 70, a csh e ksh nos fins de 70, ... ) mas a ordem (aproximada) como apareceram é. A sh foi criada para explorar alguns conceitos de unix (pipe, fork, descriptors), mas (dizem) foi mal desenhada, tanto a nivel dos puristas (dizem que a gramatica da sh nao permite que um pipe funcione), como a nivel dos programadores (dizem que as construcoes sh nao sao coerentes entre si, e tem conceitos avacalhados [bem... nunca ouvi "avacalhados", mas percebem...]).

    face a isto, entra a csh em cena, criada pelo bill joy, o homem que nos deu o vi (yes!), a empresa Sun, e que agora anda a tentar convencer/obrigar toda a gente do universo a usar java... para ter um uso interactivo mais agradavel, e uma scripting a-la C (dai o nome C-shell). Bullshit! FOi pior a emenda que o soneto. Curiosamente, muita gente usou mesmo aquilo. Mais ou menos ao mesmo tempo, o david korn fazia a ksh, mas como o homem trabalha nos bell labs (donde tinha saido o unix em primeiro lugar, e a propria bourne-sh), a ksh teve que ser compativel com a sh original (mais ou menos como o que mais tarde aconteceu do c++ em relacao ao c). na pratica a ksh ficou como uma sh + algumas coisas (sobretudo truques em substituicoes de variaveis e mais builtins). como a bell labs tinha o codigo fechado (ao contrario do bsd -- onde o bill joy desenvolveu bastante), talvez isso explique que a csh tenha ficado mais popular que a ksh.

    bom, para resumir isto, que nao tenho a noite toda, mais tarde a rapaziada de um sitio qualquer (cornnel??!) criou a tcsh - tenex csh, que era uma csh, com muito mais facilidades a nivel interactivo. e foi a primeira shell a pensar no uso interactivo e ter solucoes praticas para isso, apesar de ter sido mantida compativel com a csh. talvez isso (a parte da interactivade) explique o seu grande sucesso ainda hoje (eu uso a tcsh :) A bash apareceu mais tarde, como uma especie de tcsh em relacao a sh, ou seja, uma shell renovada, a pensar sobretudo no modo interactivo.

    de um modo geral, as tres grandes shells hoje em dia, sao de facto duas :) a bash e a tcsh. a terceira era a korn shell, mas sofreu muito por ter ate há pouco tempo atras codigo fechado. a unica implementacao livre era a PDKSH (public domain ksh) que era muito fraquinha em relacao ao ksh (embora tenha melhorado IMENSO com o tempo).

    apareceram muitas mais shells, que foram mencionadas em artigos anteriores: a zsh, criada por um paul nao-sei-quantas (estou a dizer isto de cabeca), que tentou ter tudo o que tinha a bash mais a tcsh, e acabou por ter de facto tudo, menos uma coisa: os utilizadores (da-se!). da ultima vez que vi, o autor original tinha saido, e havia uma equipa (a-la linux kernel, mas mais pequena) a desenvolver a coisa. nao sei se andara com muita vida hoje em dia. existem outras com paradigmas diferentes, como a "rc" e a "es" que sao shells funcionais.

    para as distros de repair/recovery etc etc apareceram as shell-all-in-one, que sao shells normais, com muito do fancy-stuff tirado para fora, mas com um subset dos principais comandos implementado builtin. a sash é a mais conhecida, mas lembro-me de existir pelo menos mais uma fixe (só que a idade nao perdoa e o nome ja era)

    as shells tem crescido muito em funcionalidade, mas a maior parte do tempo que lidamos com shells, mais do que ter comandos que sao modulos (e como tal carregam mais rapido e podem ser customizados, etc...) o que interessa realmente sao as facilidades de scripting e a sua utilizacao em modo interactivo.

    para scripting, estamos conversados: sh ou sh-alike. nao vale a pena pensar em mais nenhuma sheel para scripting. o problema aqui sao as incompatibilidades, coisas que quebram numas e noutras nao, e nem sequer estamos a falhar dos bashismos, mas sim dos tais pozinhos que eu falava em cima (lembram-se?) que foram sendo adicionados a sh original.

    se vao fazer scripts que querem ver a correr em diferentes sh's, as dores de cabeca comecam a aumentar exponencialmente, com pequenas coisinhas:
    1. "--" o -- pode ser usado para assinalar o fim das opcoes e comeco dos argumentos. isso e bom (leia-se é NECESSARIO) se os argumetnos comecare m com "-". dois casos em que isso da jeito é no "set -- $var", ou "trap -- 'script' sinal" mas infelizmente usar o -- vai quebrar em algumas shells
    2. for i; do ... ; done corre ... com $i a correr todos os args ($* $@), mas em algumas shells a construcao numa so linha nao funciona, tem que se fazer:
    for i
    do
    ...
    done
    3. por falar em $* e $@, entramos no quoting madness. se corrermos um script assim "./foo 'hello sucker' bla ", se usarmos $1 partimos hello e sucker, se usamos "$1" esta ok. mas para usar toda a linha (para passar a um outro comando, por exemplo). o correcto é fazer "$@", mas isso nao funciona em todas as shells -- assim, tem de se usar "$*" que nao funciona bem em alguns casos, e que ja agora, é diferente de $* (sem as aspas) que é diferent de $@ (lembram-se do avacalhado?)
    . (ja perdi a conta) os quotes via '' sao OK! os quotes via "" sao fucked up com as `` e com os escapes, que por sua vez sao lixados nas `` por si so. fazer a=`cmd` pode ser uma dor de cabeca bem pesada, se cmd produzir espacos (ou newlines) e se cmd tiver que usar chars \. experimentem!
    . as funcoes nao sao suportadas por todas as shells, ainda por cima, existem duas formas: "func_name() { ... }" e "function name ????" nao sei de cor. uso sempre a primeira.
    ah! nao facam funcoes vazias, por ha shells que suportam isso, outras nao -> "x() {}", por la pelo menos um ":"
    . outra coisa engracada e que a shell original nao possuia comentarios (segundo dizem, eu nao estava la para ver), usava-se o operador ":" , como caracter de comentario (quando na realidade é um operador, e que 99.999999% das vezes é simplesmente usado como um /bin/true portavel e rapido: "while : ; do echo xx; done" -> ciclo infinito.
    . cuidado com "export var=value"; muitas shells precisam de "var=value; export var".
    . outra que me lixa frequentemente, sao os operadores de alguns builtins, como o echo (-n , \c, | tr -d \\n??) ou ,principalmente o test -e, que existe em alguns lado, mas noutros nao.

    enfim, a lista seguia, embora uma boa parte dos problemas que surgem nao sao so da shell, mas do ambiente que esta a volta (o awk é oawk [old awk] ou nawk, ou gnu awk??), etc...

    Em relacao ao uso de interactivo, a ideia resume-se essencialmente em diminuir o numero de keystrokes ao maximo (a diminuicao é que é ao maximo, os keystrokes ao minimo). Focando na bash e tcsh, a nivel de command-line edition sao equivalentes (suportam vi-mapping e emacs-mapping, este ultimo é o melhor, especialmente: c-a inicio, c-e fim, esc-b back word, esc-f forw word, esc-backspace del previous word, esc-d del next word, sao os que eu uso mais).
    A nivel de completacao, o file-completition é suportado pela mair parte das shells com tab.
    A vantagem da tcsh (pelo menos da ultima vez que dei uma olhada à bash), eram as completitions programaveis: com uma sintaxe nao muito dificil, podemos por a tcsh a completar praticametne tudo o que quisermos. por exemplo, entre muitas ouras, tenho uma complecao particulamente engracada, que quando se faz: xmame TAB, completa com a lista de roms que tenho. xmame -TAB coloca-me todas as opcoes do xmame (da jeito para o nosound). outra engracada sao os r*** (rlogin, rsh), onde faco rlogin TAB aparecem uma lista de hosts pre-definidos. make TAB analisa a makefile e da-me os targets todos: make modTAB -> make modules[_TAB -> make modules_install :) , mount TAB, da-me todos os file systems do /etc/fstab, etc etc ...

    outra vantagem da tcsh, é a navegacao na historia: quando se carrega em esc-p, a tcsh procura para tras na historia, algo que comece com o que ja esta escrito, e continua pela historia adentro. o esc-f avanca no sentido anti-historia (previous/forward). Por exemplo "vi esc-p" vai-me saltanto por todos os vi's que usei. Ou "make esc-p". Em bash existem uns mecanismos de busca interactiva (a-la emacs) que me irrita profundamente e é menos pratico que o esc-p.

    outra coisa que se deve ter em atencao sao as facilidades de job-control. aqui a bash e equivalente a tcsh. bg fg %1 %2 ... %- %+

    quanto a alias, aqui a bash ganha, embora a tcsh seja mais competitiva do que se pensa: se se quiser um alias simples, tipo "a" é substituido por "b", em bash faz-se "alias a='b'" em tcsh faz-se "alias a 'b'" nao leva o "=". para se darem argumetnos, em bash usam-se funcoes, e aí tem-se todo o controlo do mundo, com construcoes apoiadas em scripting sh, acessiveis em dois-tres keystrokes. em tcsh isso esta muito mais limitado, mas mesmo assim pode-se conseguir bons efeitos usando o !:1 !:2 !:^ !:$ !* (primeiro, segundo, inicial, ultimo, todos argumentos "passados" no alias):
    alias e 'echo "->>\!:1>baba>baba>\!*>baba 1 2 3-

    cya

    --
    carlos (cgd no gildot)
    Re:shells, longo (Pontos:1, Informativo)
    por Anonimo Cobarde em 02-06-01 1:36 GMT (#7)

    para quem leu ate ao fim, a ultima linha era suposto ser exemplos, que ficaram lixados pelos maiores/menores.

    vamos la ver se vai la assim:


    alias e 'echo "->>\!:1<<-"'
    e baba
    ->>baba<<-
    e baba x x x
    ->>baba<<-
    alias e 'echo "->>\!*<<-"'
    e baba 1 2 3
    ->>baba 1 2 3<<-

    No hablo portugués pero ... (Pontos:1)
    por fernand0 em 02-06-01 9:16 GMT (#9)
    (Utilizador Info)
    Shell Comparison Shell-Choice - A Shell Comparison
    More info (Pontos:2)
    por MacLeod em 02-06-01 11:48 GMT (#10)
    (Utilizador Info)
    Já que estamos a falar de shells, queria só perguntar se alguém sabe/recomenda um bom manual de shell scripting.
    Re:More info (Pontos:1)
    por Programador em 02-06-01 23:51 GMT (#11)
    (Utilizador Info)
    O melhor livro que conheço sobre shell programming é este:

    Linux Programmer's Reference
    Richard Peterson
    Osborne
    ISBN: 0-07-882587-3

    Inclui referência a BASH, TCSH, Z, gcc, g++, gdb, RCS, criação/utilização de bibliotecas, autoconf e rpm, make, man, etc...

    No final do livro tens dois apêndices: um sobre TCL/TK e o outro sobre Tex/Latex.

     

     

    [ Topo | Sugerir artigo | Artigos anteriores | Sondagens passadas | FAQ | Editores | Preferências | Contacto ]