Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | 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 |
| | | | 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! |
| | | | 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... :-) |
| | | | 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.... |
| | | | 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. |
| | | | 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) |
| | | | 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<<- |
| | | | | Já que estamos a falar de shells, queria só perguntar se alguém sabe/recomenda um bom manual de shell scripting. |
| | | | | 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.
|
| |
|