Fazendo perguntas

Você pode incluir perguntas no script, para coletar as informações necessárias para montar e executar algum comando complicado.

Por exemplo, o mais legal de ter uma placa de recepção de TV é poder gravar programas usando o micro como um DVR. Porém, programas gráficos como o Xawtv e o Zapping não oferecem uma boa qualidade de gravação.

Entre os programas de modo texto, o mencoder é o que oferece melhor qualidade, mas ele oferece muitas opções e por isso não é exatamente um exemplo de amigabilidade. Como vimos no capítulo 3, o comando para gravar a programação do canal 12 da TV aberta durante uma hora, compactando em Divx4, seria:

As partes do comando que mudariam de uma chamada a outra seriam o canal (channel=12) o tempo de gravação (“-endpos 01:00:00”, para uma hora) e o arquivo que será gerado (/home/$USER/video.avi). O “$USER” é uma variável interna, que contém sempre o nome do usuário atual, muito útil em scripts.

Podemos fazer com que nosso script pergunte estas informações, armazenando tudo em variáveis e no final monte o comando. Isto transformaria um comando indigesto, de quase 400 caracteres num script amigável que sua avó poderia usar.

Existem várias formas de exibir uma pergunta na tela e armazenar a resposta numa variável. A forma mais simples seria usar o comando “echo” para mostrar a pergunta e o comando “read” para ler a resposta, como em:

O “read” faz com que o script pare e fique esperando uma resposta. Ao digitar qualquer coisa e pressionar enter, ele vai para a próxima pergunta e assim por diante até executar o último comando. Teríamos então três variáveis, “canal”, “tempo” e “arquivo” que poderíamos utilizar para montar o comando principal, que, dentro do script, ficaria:

Veja que, ao criar uma variável, simplesmente a chamamos pelo nome, mas ao utilizá-la depois precisamos usar um símbolo de dólar, “$“. É isso que faz o bash diferenciar a variável “arquivo” da palavra (ou comando) “arquivo”.

Isto já seria o suficiente para ter um script funcional. A desvantagem neste caso é que o script roda em modo texto e possui um visual muito pobre (note que ao ser executado, o script trocou o “$USER” por “kurumin”).

Existem programas que permitem incrementar o script, transformando as perguntas em janelas gráficas. Os três mais usados são o dialog, o Xdialog e o kdialog.

O dialog é o mais antigo e tradicional. Ele não gera geralmente uma janela gráfica, mas sim uma janela de modo texto, que lembra os tempos do Clipper. A vantagem é que ele permite que o script seja executado em modo texto puro ou remotamente (via ssh ou telnet), mesmo em conexões lentas.

Por exemplo, para mostrar um aviso na tela, o comando seria:

O “10 50” indica o tamanho da janela, em caracteres. O dialog é capaz de exibir vários tipos de janelas, para abrir e salvar arquivos, escolher entre opções, etc. Você pode ver todas as opções através do “man dialog“.

No nosso caso, precisamos ler a resposta, por isso usamos o parâmetro “--inputbox” do dialog:

O “10 60” indica o tamanho da janela, como já vimos. O “12” que vem a seguir é o valor default, que é assumido caso você simplesmente pressione Enter. É importante sempre usar um valor padrão nas perguntas, pois ele serve ao mesmo tempo como um exemplo do que deve ser respondido e como uma garantia que a resposta não virá em branco.

O “2> /tmp/resposta.tmp” faz com que a resposta seja gravada num arquivo de texto. Em seguida, o “canal=`cat /tmp/resposta.tmp`” cria a variável “canal”, com a resposta.

O comando cat serve para listar o conteúdo de um arquivo de texto. Originalmente ele simplesmente escreveria na tela. Mas, usado desta forma, a saída do cat (o texto dentro do arquivo) é armazenado na variável, sem ser mostrado na tela.

O resultado é o mesmo do exemplo anterior, mas desta vez com uma interface um pouco melhor:

O Xdialog possui quase as mesmas opções e sintaxe do dialog, mas gera janelas gráficas. O maior problema é que nem todas as distribuições trazem o Xdialog instalado por padrão. Nestes casos você pode baixar a versão mais recente no: http://xdialog.dyns.net/.

Em distribuições derivadas do Debian, você pode instalá-lo via apt-get; o pacote está disponível nos servidores principais. No caso das distribuições que usam pacotes rpm procure nohttp://www.rpmfind.net/linux/RPM/.

Veja que as opções são exatamente iguais ao exemplo anterior; muda apenas o comando:

Outras funções muito usadas no Xdialog e no dialog são:

--radiolist: Esta função permite exibir um menu de opções, que uso freqüentemente nos scripts dos ícones mágicos do Kurumin. Veja, por exemplo, o script “instalar-bluefish”, disponível dentro da pasta “/usr/local/bin/” no Kurumin, ou no https://www.hardware.com.br/kurumin/scripts/.

--yesno: Permite fazer perguntas. A resposta é armazenada automaticamente na variável “$?”, que você pode checar em seguida. Se a resposta foi “sim”, a variável fica com o valor “1” e se for “não”, fica com o valor “0”. Um exemplo de uso seria:

Xdialog --yesno "Tem certeza que deseja instalar o programa?" 15 60
if [ "$?" = "0" ] ; then
    comandos...
fi

--fselect: Abre um menu de seleção de arquivos. Pode ser usado ao abrir um arquivo, por exemplo. Este é um exemplo rápido que permite escolher um arquivo e tenta abri-lo usado o mplayer:

Xdialog --fselect ./ 30 75 2> /tmp/resposta.tmp
video=`cat /tmp/resposta.tmp`; rm -f /tmp/resposta.tmp
mplayer "$video"

--dselect: É similar ao –fselect, mas abre um menu para escolher um diretório.

O kdialog, por sua vez, é um componente do KDE e por isso é o ideal para ser usado em distribuições que trazem o KDE como desktop principal. As janelas seguem o padrão visual do KDE, respeitando as configurações de cor, fontes e ícones definidas no Centro de Controle do KDE, o que deixa os scripts com uma aparência muito mais profissional.

A principal desvantagem é que, justamente por ser baseado nas bibliotecas do KDE, ele fica mais lento e pesado ao ser usado no Gnome ou outras interfaces, pois para abrir uma simples janela de aviso será preciso carregar as bibliotecas do KDE.

Para abrir a mesma janela em kdialog, o comando seria:

Veja que aqui estou atribuindo o resultado do comando (a resposta) diretamente à variável (como no exemplo do md5sum), ao invés de ter que salvar num arquivo e depois lê-lo. Leríamos: canal é igual ao resultado de kdialog –title “Gravar-TV” –inputbox “Canal a gravar (ex: 12)” “12”.

Isso funciona no kdialog e não no dialog ou Xdialog, pois o kdialog envia a resposta para a saída padrão (que seria exibida no terminal), enquanto o Xdialog envia para a saída de erro. Se você quisesse fazer como nos exemplos anteriores, salvando num arquivo e lendo-o em seguida, haveria uma pequena mudança no comando:

Note que, ao invés de usar “2> /tmp/resposta.tmp”, usei “> /tmp/resposta.tmp. O “2>” serve para direcionar a saída de erro, enquanto o “>” direciona a saída padrão, fazendo com que ao invés de mostrar na tela, o comando salve o texto dentro do arquivo.

É possível usar ainda o “&>”, que direciona simultaneamente ambas as saídas. Por exemplo, é comum que os programas do KDE exibam várias mensagens ao serem abertos num terminal, “sujando” a tela. Uma forma de resolver o problema é direcionar ambas as saídas para o /dev/null, como em:

O parâmetro “–title” permite especificar o texto do título da janela. Este parâmetro também existe no dialog e Xdialog. Note que desta vez não especifiquei as dimensões da janela. No kdialog isto não é necessário, pois a janela é dimensionada de acordo com o conteúdo. Você pode ter um efeito similar no Xdialog colocando as dimensões como “0 0”. Nossa janela em kdialog fica:

Este é o script completo, que desenvolvi para o Kurumin usando janelas em kdialog. O script está dividido em várias partes, intercaladas com explicações:

A opção –getsavename do kdialog, usada na função abaixo abre uma janela do gerenciador de arquivos, para que o usuário aponte a pasta e o nome do arquivo. A opção :label1 faz com que a janela mostre apenas arquivos com as extensões “.avi, .mpg e .wmf”, ou seja, apenas arquivos de vídeo. Esta mesma função pode ser usada em outras situações, onde você escrever scripts que precisam salvar ou abrir arquivos de formatos específicos.

As quebras de linha dentro do texto da opção fazem com que o texto fique formatado da mesma maneira dentro da janela. Este é mais um ponto de discórdia entre o kdialog e o Xdialog. No primeiro, ao quebrar o texto dentro do script, ele é automaticamente incluído da mesma forma na janela, enquanto no Xdialog é necessário especificar as quebras de linha manualmente usando o “\n”.

A opção “–passivepopup” (disponível apenas no Kdialog) mostra um aviso que some depois do tempo especificado (neste caso depois de 6 segundos), ou ao clicar sobre a janela:

Aqui vai o comando de gravação, montado usando todas as informações coletadas acima. Depois do comando de gravação, ou seja, depois que a gravação termina, é mostrada mais uma janela de texto, usando o “–passivepopup”, desta vez sem o número que especifica o tempo de exibição. Isto faz com que a janela fique no canto da tela até receber um clique se confirmação.

O “exit” é um comando que denota o fim do script. O “0” é o status de saída, que pode ser lido por programas executados em seguida, no mesmo terminal. O 0 indica que o script terminou normalmente, mas você pode incluir vários “exit” dentro de condicionais e partes específicas do scripts, permitindo que ele “termine de forma elegante” em caso de erros, com um código de saída que permita verificar o que aconteceu.

Este outro script, também escrito para o Kurumin, serve para montar compartilhamentos de rede em NFS. Diferentemente do script de gravar TV, ele foi escrito para funcionar tanto dentro do modo gráfico (usando janelas em Xdialog) ou em modo texto puro, usando o dialog. Uma função no início do script se encarrega de detectar se o modo gráfico está aberto ou não.

Você pode encontrar todos os scripts desenvolvidos para o Kurumin dentro da pasta /usr/local/bin/ do sistema, ou online no: https://www.hardware.com.br/kurumin/bin/.

Eles são intencionalmente escritos de forma simples, até elementar para facilitar o entendimento. Tudo começa com o “#!/bin/sh”, que denota que se trata de um shell script. É de praxe incluir também uma descrição do programa e o nome do autor:

Esta variável ativa o modo de compatibilidade do Xdialog, que melhora a aparência das janelas. Ela é opcional, mas é complicado acertar o texto dentro das janelas sem ela, pois o Xdialog não ajustará automaticamente o texto dentro da janela (faça um teste e veja a diferença). É interessante usá-la em qualquer script que use o Xdialog.

Este script corresponde ao ícone “NFS – Montar Compartilhamento” no iniciar. Ele facilita o acesso a compartilhamentos NFS que normalmente são uma tarefa um tanto quanto indigesta para os iniciantes.

Ele começa perguntando ao usuário qual compartilhamento será montado. Aqui estamos usando as opções “–ok-label” e “–cancel-label” do Xdialog, que alteram o texto dos botões, ajustando-os melhor ao seu script. A opção “–inputbox” faz com que a janela seja exibida como uma pergunta, onde você deve informar o endereço IP do servidor e a pasta compartilhada. Os números “21 70” definem as dimensões da janela (em caracteres) e o ‘192.168.0.1:/arquivos’ é o texto padrão, que aparece no campo de resposta da pergunta. Como disse anteriormente, é importante incluir sempre uma resposta default na pergunta, o que previne erros e enganos. O “\n” adiciona uma quebra de linha, permitindo formatar o texto.

O “2> /tmp/nfs1” faz com que a resposta seja escrita num arquivo (ao invés de ser mostrada na tela). Fazemos com que este arquivo seja lido usando o cat e atribuímos a resposta à variável “SHARE”, que inclui o texto digitado na janela.

Além de saber qual compartilhamento será montado, é preciso saber onde ele será montado. Esta pergunta inclui a pasta “/mnt/nfs” como resposta padrão, que seria um local adequado. Caso o usuário não precise montar num local específico, ele vai simplesmente pressionar Enter, fazendo com que a pergunta não incomode.

Temos agora mais uma variável, agora armazenando o texto com o diretório local onde o compartilhamento será montado.

Esta função verifica se o local informado existe e é realmente um diretório (-d) e faz uma dupla checagem: se ele existe, é usado o comando umount, para ter certeza de que não existe outro compartilhamento ou partição já montada na pasta. Caso ela não exista, o script usa o mkdir para criá-la. É sempre saudável incluir este tipo de checagem em seus scripts, tentando antecipar erros e dificuldades comuns por parte de quem vai usar e incluindo ações apropriadas para cada um.

if [ -d $LOCAL ]; then
    umount $LOCAL
else
    mkdir $LOCAL
fi

Vamos agora iniciar alguns serviços necessários para o NFS funcionar. Não sabemos se eles vão estar ou não abertos na máquina alvo, por isso é melhor ter certeza.

Ao mesmo tempo em que os comandos são executados, eles são escritos na tela, o que tem uma função didática. O sleep 1 faz com que o script pare por um segundo ao executar cada um dos comandos, dando tempo para que qualquer mensagem de erro seja notada.

As duas variáveis que foram lidas acima são usadas para montar o comando que acessa o compartilhamento:

Esta linha remove os arquivos temporários que foram usados. É importante deixar a casa limpa, até para evitar problemas caso o script seja executado várias vezes em seguida. Veja mais adiante a dica de como criar arquivos temporários dinâmicos.

Concluindo, abrimos uma janela do Konqueror já mostrando os arquivos do compartilhamento, provendo gratificação imediata. O “&” no final do comando permite que o script continue, mesmo que a janela permaneça aberta, enquanto o “&>/dev/null” esconde os avisos e erros que o Konqueror costuma exibir, evitando que ele suje o terminal:

O “&>/dev/null é um redirecionador, que envia qualquer mensagem ou erro que seria mostrado no console para o /dev/null, o “buraco negro” do sistema. Isso é importante no caso de programas como o Konqueror, que sujam a tela com um sem número de mensagens.

Uma outra forma de fazer a mesma coisa, é colocar o comando que deve ser “silenciado” dentro de “:“”, como em “:`konqueror $LOCAL`”. O “:” é, por estranho que pareça, um comando do shell, que simplesmente não faz nada. Usado desta forma, ele recebe as mensagens exibidas pelo comando e não faz nada. Este é um dos casos em que você pode fazer a mesma coisa usando um comando mais longo, porém mais legível, ou escrever da forma com menos caracteres.

Depois de montar o compartilhamento, entra em ação a segunda parte do script, que oferece a opção de adicionar uma entrada no fstab e criar um ícone no desktop para montar o compartilhamento. A variável “$?” armazena a resposta da pergunta. Se a resposta for sim, ela armazena o valor “0”; e se for não, armazena “1”. O script checa o valor e continua apenas se for 0.

Da mesma forma que é usado para escrever na tela, o “echo” pode ser usado para adicionar linhas em arquivos de configuração. Neste caso usamos os redirecionadores (>>), especificando o arquivo. O echo “” adiciona uma linha em branco no final do arquivo, o que é uma regra no caso do fstab.

Existe a possibilidade da mesma linha ser adicionada mais de uma vez ao fstab, caso o script seja executado novamente com as mesmas opções. Para evitar isso, o script primeiro checa se a linha já não existe (usando o grep) e adiciona a linha apenas se o resultado for negativo. Veremos mais exemplos do uso do grep, sed e outras ferramentas para filtrar e modificar arquivos mais adiante. Faça uma nota mental de voltar a este exemplo depois de terminar de ler todo o capítulo.

CHECK=`cat /etc/fstab | grep "$SHARE $LOCAL nfs noauto,users,exec,soft 0 0"`

if [ -z "$CHECK" ], then
    echo '# Acessa compartilhamento nfs, adicionado pelo nfs-montar:' >> /etc/fstab
    echo "$SHARE $LOCAL nfs noauto,users,exec,soft 0 0" >> /etc/fstab
    echo "" >> /etc/fstab
fi

Por fim, é criado um ícone no desktop permitindo montar o mesmo compartilhamento facilmente depois. Os ícones do KDE são apenas arquivos de texto comuns, por isso podem ser facilmente criados através de scripts.

Aqui temos mais um problema: Se forem criados vários ícones para compartilhamentos, cada um precisará ter um nome de arquivo diferente. Seria possível pedir para que fosse digitado um número, por exemplo, e usá-lo como nome para o arquivo, mas nada impediria que o usuário simplesmente digitasse o mesmo número repetidamente, o que não resolveria nosso problema.

Uma solução é usar o comando “date”, que informa a hora atual, para gerar um número que pode ser usado como nome do arquivo. O que aparece escrito no desktop não é o nome do arquivo, mas sim o campo “Name” dentro do texto. Usado com os parâmetros abaixo, o date retorna algo como “20060228952”. O “fi” usado aqui fecha o “if” aberto anteriormente e o “exit 0” indica o final do script:

    NOME=`date +%Y%m%d%H%M`

    echo "[Desktop Entry]" > ~/Desktop/$nome
    echo "Type=FSDevice" >> ~/Desktop/$nome
    echo "Dev=$SHARE" >> ~/Desktop/$nome
    echo "MountPoint=$LOCAL" >> ~/Desktop/$nome
    echo "FSType=nfs" >> ~/Desktop/$nome
    echo "ReadOnly=0" >> ~/Desktop/$nome
    echo "Icon=hdd_mount" >> ~/Desktop/$nome
    echo "UnmountIcon=hdd_unmount" >> ~/Desktop/$nome
    echo "Name=$SHARE" >> ~/Desktop/$nome

fi
exit 0

Uma dúvida freqüente é sobre o uso das aspas. Num script você pode tanto utilizar aspas duplas (“), quanto aspas simples (‘), mas as duas possuem funções ligeiramente diferentes.

As aspas duplas fazem com que o conteúdo seja interpretado literalmente, isso permite incluir nomes de arquivos com espaços entre outras coisas. As aspas simples fazem o mesmo, mas de uma forma mais estrita, sem interpretar variáveis.

Por exemplo, o comando: echo “mount -o soft -t nfs $SHARE $LOCAL” do script anterior usa duas variáveis. Ao executar o script elas são substituídas pelos valores correspondentes, fazendo com que seja mostrado na tela algo como: “mount -t nfs 192.168.0.1/arquivos /mnt/nfs”.

Porém, se usássemos aspas simples, como em: echo ‘mount -t nfs $SHARE $LOCAL’, o resultado do comando seria diferente. O bash escreveria a frase literalmente, sem interpretar as variáveis e veríamos na tela: “mount -t nfs $SHARE $LOCAL”.

Ou seja, só usamos aspas simples quando realmente queremos usar um bloco de texto que não deve ser interpretado de forma alguma nem conter variáveis. No restante do tempo, usamos sempre aspas duplas.

No final do script, escrevo o ícone do desktop linha a linha, usando aspas duplas. Note que na primeira linha usei um “>” ao invés de “>>” como nas seguintes. Assim como no caso das aspas, o redirecionador simples tem um efeito diferente do duplo.

O simples (>) apaga todo o conteúdo anterior do arquivo, deixando apenas a linha adicionada. Ele é usada em situações onde você quer ter certeza de que o arquivo está vazio ao invés de deletar e criar o arquivo novamente. O redirecionador duplo, por sua vez, simplesmente adiciona texto no final do arquivo, sem modificar o que já existe.

Continuando, uma opção interessante do comando “read” que vimos a pouco é o “-t” (timeout), que permite especificar um tempo máximo para a resposta. Se nada for digitado, o script continua.

Esta opção pode ser usada para incluir opções do tipo “Pressione uma tecla dentro de 5 segundos para acessar a janela de configurações”, onde o script deve continuar se não receber nenhuma resposta. Um exemplo seria:

echo "Pressione uma tecla em 3 segundos para abrir a configuração."
read -t 3 resposta
if [ -n "$resposta" ]; then
    configura-programa
fi
abrir-programa

Este é o tipo de função que pode ser usada na abertura do programa, por exemplo. A função “if [ -n “$resposta” ]” verifica se a variável resposta contém alguma coisa. Caso contenha, significa que foi digitado alguma coisa, o que dispara o comando que abre o menu de configuração. No final, é sempre executado o comando que abre o programa, tenha sido aberta a janela de configuração ou não.

Ao invés de usar o if, você pode incluir operações de verificação de forma mais compacta usando o “&&” (que testa se uma condição é verdadeira) e o “||” (que testa se ela é falsa). Por exemplo, ao invés de usar:

if [ -n "$resposta" ]; then
    configura-programa
fi

Você poderia usar:

Aqui ele verifica se a variável resposta está vazia (-n) e, caso esteja, executa o comando “configura-programa”. Como pode ver, ele tem a mesma função que o “then” do if.

O “||” por sua vez, verifica se a condição é falsa, tendo uma função similar à do “else”. A principal vantagem é que ele pode ser usado diretamente, sem necessidade de incluir um if inteiro, como em:

Aqui ele verifica se o md5sum do arquivo está correto e mostra a mensagem apenas quando ele não bater.

Tanto o && quanto o || podem ser usados também para testar comandos, avisando caso o comando seja executado corretamente, ou caso surja algum erro, como em: