10 dicas para temperar seus scripts shell – quantas delas você já usou?
Este artigo do nixCraft apresenta 10 ferramentas para acrescentar algum tempero à interface dos seus scripts shell, indo bem além do echo e read – quando o ambiente de execução permite, é claro.
Tem dicas old school, como o tput, que permite alguma portabilidade no controle do visual do que é impresso no terminal, mas ainda mantém a cara de TTY que os profissionais da área conhecem há décadas, conforme visto na ilustração acima.
E há dicas mais apropriadas aos ambientes desktop mais recentes, como o notify-send, mostrado acima.
E no meio do caminho tem bem mais ferramentas interessantes, incluindo setleds, zenity, kdialog, dialog, logger, setterm, envio de mensagens com o smbclient, e sockets no Bash.
Fiz uma contagem rápida e percebi que já usei 8 das 10 ferramentas acima, o que certamente indica que já fiz minha cota de scripts pouco portáveis entre ambientes POSIX ;-)
You can easily use various tools to write GUI and/or network (socket) scripts under KDE or Gnome desktops. Shell scripts can make use of some of the GUI widget (menus, warning boxs, progress bars etc). (via cyberciti.biz)
@brlinuxblog
Feed RSS
O gnome vem com o zenity, mas o zenity deve ser usado com cautela, pois cada vez que você o executa, a janela grafica construida solta para frente e remove o foco do que você esteja fazendo.
Eu tive que abandonar algumas sintaxes do zenity por causa disso, o –progress por exemplo não pode ser usado sequencialmente em intervalos menores porque incapacita o operador de digitar um texto enquanto o script está rodando estas instruções.
O notify-send não vem com debian/ubuntu tendo que ser instalado posteriormente, além disso, há um bug em que o “-t tempo” não permite especificar o tempo de uma mensagem na tela.
Bom, estou falando dos problemas do zenity, o qual uso.
Aqui está um trocado garoto, vá aprender a programar em uma linguagem de programação de verdade.
Programinhas como esses apresentados são umas das coisas mais divertidas de fazer scripts shell.
É bacana ver aquele seu scriptzinho shell virando algo mais incrementado, com saída GUI.
Eu tinha (ou ainda tenho? rs) a ilusão de ser o próprio hacker. rs
Valeu pelas dicas Augusto. =)
Abs!
Um bom Shell Script evita usar estas coisas não-portáveis por padrão. Um bom Shell Script deve funcionar perfeitamente bem com as ferramentas básicas disponíveis em qualquer sistema. Mas depois que o seu “bom Shell Script” está pronto, dependendo da tarefa, pode ser interessante usar estas perfumarias. Mas é claro, o shell script sempre deve verificar a disponibilidade destas coisas não-padronizadas antes de tentar usar. E não deve se tornar dependente delas.
Tá ai a sarna que eu precisava pra me coçar no dia de Tiradentes.
Vai de shell. :)
@zer0c00l,
Fazendo referencias ao objetivo da linguagem Python :
“Se a implementação é difícil de explicar, então é má ideia.
Se a implementação é fácil de explicar então pode ser uma boa ideia”
Quem programa, programa em mais de uma linguagem de programação então seu comentário foi completamente desnecessário. A julgar pelo seu comentário, você deve criar ferramentas de backup, automatização ou integração entre servidores só escrevendo em C/C++, né ? Ignorando que shell script resolve situações em instantes de forma fácil.
O zer)c))L gosta de falar mal do fusca do vizinho comparando ele ao seu Palio, mesmo que o fusca do vizinho seja mais fácil de manter, possua menos necessidade de energia, tenha menos necessidade de manutençãões programadas, custe pouco para adquirir, seja fácil de implementar upgrades e possua uptime aceitável em relação ao custo de aquisição.
Fazer o quê…
Custo vs benefício é uma equação que não entra na cabeça de todo mundo.
O fusca não é ruim por natureza. Ele só não serve para corridas (geralmente). Mas é uma boa solução dependendo do caso.
Uma coisa que eu não gosto é que, hoje em dia a maioria dos artigos sobre shell-script falam muito pouco sobre as funções da “linguagem” e logo GUIzilam. Pootz, não tenho NENHUM shell script com GUI em produção, o mais próximo disso, na minha “suite” pessoal, é apenas um script de clonagem via rede que utiliza Dialog – e isso por que eu estava numa senhora preguiça de construir a interface em ASCII puro quando o fiz. Echo e printf FTW! Pra mim é perfumaria, não é o que realmente interessa. Então, normalmente recorro ao man bash.
@Lucas Timm, tbm percebo isso. Para mim shell-script é uma excelente classe de linguagem, mas querem extravasar seu uso, e um caso típico são os programas com interface gráfica.
Criar interfaces gráficas com shell-script não é algo natural, ao meu ver. Natural digo no sentido das linguagens “normais”, onde vc trata widgets e janelas como variáveis, objetos de fácil manipulação.
Para mim shell-script serve pra vc juntar aquele monte de programas, cada um fazendo uma coisa, independente da linguagem que foi implementada, para fazer algo maior.
Isso significa que um “comando” em shell-script pode ser um programa que tanto faz ser implementado em C, assembly, python,zsh, ser um built-in, função, alias, php, basic, sei lá, desde que receba uma entrada (stdin), devolva uma saída (stdout ou stderr) ou um valor de retorno ($?). E isso todas as linguagens de programação implementam.
Para mim esta é a verdadeira riqueza da “linguagem”.
Mas programas para cálculos com números reais, por exemplo, são difíceis de serem implementados em shell-script. Embora shell-script tenha algumas coisas que lembram orientação a objetos (um array tem vários “métodos” associado a ele, como substring, tamanho, etc), não é boa para programar orientado a objetos (embora eu não duvide que seja possível emular este comportamento!) ou mesmo para coisas simpels que envolvam matrizes de duas ou mais dimensões.
Mas é legal para coisas como rodar um loop que vai conectando automático em várias máquinas num laboratório via ssh, jogando este processo para background (não necessitando esperar terminar para ir ao próximo) e em cada máquina ativar um loop que a cada 5s abre e fecha a bandeja do drive de cd, todas as máquinas juntas :-)
Sim, eu já fiz isso uma vez há vários anos atrás, mas aconselho que ninguém o faça. É assustador, mas necessita que vc use vários conhecimentos em shell, como o uso do eval, laços, jobs, etc :-) Como em cada máquina tbm jogo o processo em bg e saio para não aparecer como usuário logado, o processo só finaliza se for morto pelo administrador ou a máquina desligada.
Hoje eu sou mais consciente e não faço mais isso. Ainda bem que o lab estava com pouca gente :-)
Ah sim, eu não conhecia este suporte à sockets. Muito bom mesmo! :-)
Tem tbm um comando chamado socket (é um programa, não um built-in) que possibilita vc criar servidores que ficam escutando numa determinada porta, e pode ler os dados via entrada padrão. Mas eu nunca cheguei a utilizá-lo efetivamente.
Ele é bem útil caso vc queira automatizar algum serviço numa rede interna, mas não implementa mecanismo de segurança por padrão :-)
$ man 1 socket
@tenchi
Essas extensoes para bash como o zenity nao substituem de forma alguma interfaces graficas completas, alias nem chegam perto disso.
Essas extensoes apenas facilitam a entrada de dados por parte do usuario, veja a situacao :
echo “Digite o caminho completo para o arquivo”
read caminho
if [ -f "$caminho" ] ; then …
Veja a versao com zenity :
zenity –title=”Digite o caminho completo para o arquivo ” –file-selection
Com o zenity o camarada nao erra ao digitar um caminho longo porque vai usar uma janela de dialogo grafica e se eu quiser posso suprimir a verificacao se o arquivo digitado existe ou nao.
Sao poucas operacoes graficas existentes no dialog/zenity/kdialog, que so existem para facilitar operacoes com o interlocutor e nao para ser mais “bonitinha”.
Tem uso plausivel se voce ja tem uma interface grafica em seu sistema.
Tenho me divertido bastante com o bigbashview, nada como ver seu shellscript interagindo com o Jquery :D
Toda aquela discussão sobre o BigLinux serviu para eu conhecer esse programinha pra la de porreta!
@hamacker, sim. Não disse que programas em shell não podem ter interface gráfica (peço desculpas se pareceu iso), mas tem gente que acaba extrapolando ;-)
Um exemplo é o painel de controle do Kurumin (eu me lembro das primeiras versões), que era feito usando uma combinação de kommander e bash. Está certo que não era bash puro e com o kommander vc pode escrever usando qualquer linguagem de script. Vc cria um programa extremamente complexo, mas que não tem cara de um sistema com uma arquitetura boa :-)
Teve um programinha que eu fiz pro laboratório da faculdade onde eu estudo que serve para o usuário remover, de forma interativa, arquivos que estejam fazendo com que ele ultrapasse a quota (de 50MB somente) que antes deveria ser feito com uma concatenação de trocentos comandos. E, mesmo sendo um laboratório de um curso na área da computação, a maioria dos usuários não tem tanta intimidade com a linha de comando.
O programa lista todos os arquivos, diretórios (inclusive ocultos), seguido pelo tamanho em MB ou KB, ordenado – descendente – pelo tamanho do mesmo. O usuário vai selecionando com o teclado, e depois clica em OK. A próxima tela (tudo em dialog puro, obrigado Aurélio) é pedida uma confirmação de exclusão e depois os arquivos são excluidos um a um.
Uma interface gráfica onde interface gráfica ajuda, bem nestes moldes q vc disse.
Tinha um programa mantido pelo projeto enlightenment q permitia que vc criasse interfaces mais complexas (não só como os dialogs da vida) baseado em layout, buttons, hbox, menu, etc., em qualquer linguagem de script, tudo baseado em escrita/leitura em sockets e named pipes. Era muito interessante, mas não é mais mantida, e vai de encontro a tudo que eu disse acima, mas não deixa de ser interessante :-)