Papo de Botequim - Parte X

- E aê amigo, te dei a maior moleza, né? Um exerciciozinho muito simples...

- É mais nos testes que eu fiz, e de acordo com o que você ensinou sobre substituição de parâmetros, achei que deveria fazer outras alterações nas funções que desenvolvemos para torná-las de uso geral como você me disse que todas as funções deveriam ser, quer ver?

- Claro né mané, se te pedi para fazer é porque estou afim de te ver aprender, mas peraí, dá um tempo!

- Chico! Manda dois, um sem colarinho!

- Vai, mostra aí o que você fez.

- Bem, além do que você pediu, eu reparei que o programa que chamava a função, teria de ter previamente definidas a linha em que seria dada a mensagem e a quantidade de colunas. O que fiz foi incluir duas linhas - nas quais empreguei substituição de parâmetros - que caso uma destas variáveis não fosse informada, a própria função atribuiria. A linha de mensagem seria três linhas acima do fim da tela e o total de colunas seria obtido pelo comando tput cols. Veja como ficou:

- Gostei, você já se antecipou ao que eu ia pedir. Só pra gente encerrar este papo de substituição de parâmetros, repare que a legibilidade está horrorível, mas a performance, isto é, velocidade de execução, está ótima. Como funções são coisas muito pessoais, já que cada um usa as suas, e quase não dão manutenção, eu sempre opto pela performance.

- Hoje vamos sair daquela chatura que foi o nosso último papo e vamos voltar à lógica saindo da decoreba, mas volto a te lembrar, tudo que eu te mostrei da outra vez aqui no Boteco do Chico é válido e quebra um galhão, guarde aqueles guardanapos que rabiscamos que, mais cedo ou mais tarde, vão te ser muito úteis.

O comando eval

- Vou te dar um problema que eu duvido que você resolva:

- Te dei estas duas variáveis, e quero que você me diga como eu posso, só me referindo a $var2, listar o valor de $var1 (3).

- A isso é mole, é só fazer:

    echo $`echo $var2`

- Repare que eu coloquei o echo $var2 entre crases (`), que desta forma terá prioridade de execução e resultará em var1, montando echo$var1 que produzirá 3...

- A é? Então execute para ver se está correto.

- Ué! Que foi que houve? O meu raciocínio me parecia bastante lógico...

- O seu raciocínio realmente foi lógico, o problema é que você esqueceu de uma das primeiras coisas que te falei aqui no Boteco e vou repetir. O Shell usa a seguinte ordem para resolver uma linha de comandos:

• Resolve os redirecionamentos;
• Substitui as variáveis pelos seus valores;
• Resolve e substitui os meta caracteres;
• Passa a linha já toda esmiuçada para execução.

Desta forma, quando chegou na fase de resolução de variáveis, que como eu disse é anterior à execução, a única variável existente era $var2 e por isso a tua solução produziu como saída $var1. O comando echo identificou isso como uma cadeia e não como uma variável.

Problemas deste tipo são relativamente freqüentes e seriam insolúveis caso não existisse a instrução eval, cuja sintaxe é:

    eval cmd

Onde cmd é uma linha de comando qualquer que você poderia inclusive executar direto no prompt do terminal. Quando você põe o eval na frente, no entanto, o que ocorre é que o Shell trata cmd como se seus dados fossem parâmetros do eval e em seguida o eval executa a linha recebida, submetendo-a ao Shell, dando então na prática duas passadas em cmd.

Desta forma se executássemos o comando que você propôs colocando o eval à sua frente, teríamos a saída esperada, veja:

Este exemplo também poderia ter sido feito da seguinte maneira:

Na primeira passada a contrabarra (\) seria retirada e $var2 seria resolvido produzindo var1, para a segunda passada teria sobrado echo $var1, que produziria o resultado esperado.

Agora vou colocar um comando dentro de var2:

Vou executar:

Agora vamos colocar em var2 o seguinte: ls $var1; e em var1 vamos colocar l*, vejamos:

Novamente, no tempo de substituição das variáveis, $var1 ainda não havia se apresentado ao Shell para ser resolvida, desta forma só nos resta executar o comando eval para dar as duas passadas necessárias.

Uma vez um colega de uma excelente lista sobre Shell Script, colocou uma dúvida: queria fazer um menu que numerasse e listasse todos os arquivos com extensão .sh e quando o operador escolhesse uma opção, o programa correspondente seria executado. A minha proposta foi a seguinte:

Parece complicado porque usei muito printf para formatação da tela, mas é bastante simples, vamos entendê-lo: o primeiro printf foi colocado para fazer o cabeçalho e logo em seguida comecei a montar dinamicamente a variável $CASE, na qual ao final será feito um eval para execução do programa escolhido. Repare no entanto que dentro do loop do for existem dois printf: o primeiro serve para formatar a tela e o segundo para montar o case (se antes do comando read você colocar uma linha echo "$CASE", verá que o comando case montado dentro da variável está todo indentado. Frescura, né? :). Na saída do for, foi adicionada uma linha à variável $CASE, para no caso de se fazer uma opção inválida, ser executada uma função externa para dar mensagens de erro.

Vamos executá-lo para ver a saída gerada:

Neste programa seria interessante darmos uma opção de término, e para isso seria necessário a inclusão de uma linha após o loop de montagem da tela e alterarmos a linha na qual fazemos a atribuição final do valor da variável $CASE. Vejamos como ele ficaria:

Sinais de Processos

Existe no Linux uma coisa chamada sinal (signal). Existem diversos sinais que podem ser mandados para (ou gerados por) processos em execução. Vamos de agora em diante dar uma olhadinha nos sinais mandados para os processos e mais à frente vamos dar uma passada rápida pelos sinais gerados por processos.

Sinais assassinos

Para mandar um sinal a um processo, usamos normalmente o comando kill, cuja sintaxe é:

    kill -sig PID

Onde PID é o identificador do processo (Process IDentification ou Process ID). Além do comando kill, algumas seqüências de teclas também podem gerar sig. A tabela a seguir mostra os sinais mais importantes para monitorarmos:

Além destes sinais, existe o famigerado -9 ou SIGKILL que, para o processo que o está recebendo, equivale a meter o dedo no botão de desliga do computador o que seria altamente indesejável já que muitos programas necessitam "limpar o meio de campo" ao seu término. Se o seu final ocorrer de forma prevista, ou seja se tiver um término normal, é muito fácil de fazer esta limpeza, porém se o seu programa tiver um fim brusco muita coisa pode ocorrer:

• É possível que em um determinado espaço de tempo, o seu computador esteja cheio de arquivos de trabalho inúteis
• Seu processador poderá ficar atolado de processos zombies e defuncts gerados por processos filhos que perderam os pais;
• É necessário liberar sockets abertos para não deixar os clientes congelados;
• Seus bancos de dados poderão ficar corrompidos porque sistemas gerenciadores de bancos de dados necessitam de um tempo para gravar seus buffers em disco (commit).

Enfim, existem mil razões para não usar um kill com o sinal -9 e para monitorar fins anormais de programas.

O trap não atrapalha

Para fazer a monitoração descrita acima existe o comando trap cuja sintaxe é:

    trap "cmd1; cmd2; cmdn" S1 S2 ... SN

ou

    trap 'cmd1; cmd2; cmdn' S1 S2 ... SN

Onde os comandos cmd1, cmd2, cmdn serão executados caso o programa receba os sinais S1 S2 ... SN.

As aspas (") ou os apóstrofos (') só são necessários caso o trap possua mais de um comando cmd associado. Cada um dos cmd pode ser também uma função interna, uma externa ou outro script.

Para entender o uso de aspas (") e apóstrofos (') vamos recorrer a um exemplo que trata um fragmento de um script que faz um ftp para uma máquina remota ($RemoComp), na qual o usuário é $Fulano, sua senha é $Segredo e vai transmitir o arquivo contido em $Arq. Suponha ainda que estas quatro variáveis foram recebidas em uma rotina anterior de leitura e que este script é muito usado por diversas pessoas da instalação. Vejamos este trecho de código:

ftp -ivn $RemoComp << FimFTP >> /tmp/$$ 2>> /tmp/$$
    user $Fulano $Segredo
    binary
    get $Arq
FimFTP

Repare que, tanto as saídas do dos diálogos do ftp, como os erros encontrados, estão sendo redirecionados para /tmp/$$, o que é uma construção bastante normal para arquivos temporários usados em scripts com mais de um usuário, porque $$ é a variável que contém o número do processo (PID), que é único, e com este tipo de construção evita-se que dois ou mais usuários disputem a posse e os direitos sobre o arquivo.

Caso este ftp seja interrompido por um kill ou um <CTRL+C>, certamente deixará lixo no disco. É exatamente esta a forma como mais se usa o comando trap. Como isto é trecho de um script, devemos, logo no seu início, como um de seus primeiros comandos, fazer:

    trap "rm -f /tmp/$$ ; exit" 0 1 2 3 15

Desta forma, caso houvesse uma interrupção brusca (sinais 1, 2, 3 ou 15) antes do programa encerrar (no exit dentro do comando trap), ou um fim normal (sinal 0), o arquivo /tmp/$$ seria removido.

Caso na linha de comandos do trap não houvesse a instrução exit, ao final da execução desta linha o fluxo do programa retornaria ao ponto em que estava quando recebeu o sinal que originou a execução deste trap.

Este trap poderia ser subdividido, ficando da seguinte forma:

    trap "rm -f /tmp/$$" 0
    trap "exit" 1 2 3 15

Assim ao receber um dos sinais o programa terminaria, e ao terminar, geraria um sinal 0, que removeria o arquivo. Caso seu fim seja normal, o sinal também será gerado e o rm será executado.

Note também que o Shell pesquisa a linha de comandos uma vez quanto o trap é interpretado (e é por isso que é usual colocá-lo no início do programa) e novamente quando um dos sinais listados é recebido. Então, no último exemplo, o valor de $$ será substituído no momento que o comando trap foi lido da primeira vez, já que as aspas (") não protegem o cifrão ($) da interpretação do Shell.

Se você desejasse que a substituição fosse realizada somente quando recebesse o sinal, o comando deveria ser colocado entre apóstrofos ('). Assim, na primeira interpretação do trap, o Shell não veria o cifrão ($), porém os apóstrofos (') seriam removidos e finalmente o Shell poderia substituir o valor da variável. Neste caso, a linha ficaria da seguinte maneira:

    trap 'rm -f /tmp/$$ ; exit' 0 1 2 3 15

Suponha dois casos: você tem dois scripts que chamaremos de script1, cuja primeira linha será um trap e script2, sendo este último colocado em execução pelo primeiro, e por serem dois processos, terão dois PID distintos.

• 1º Caso: O ftp encontra-se em script1
  Neste caso, o argumento do comando trap deveria vir entre aspas (") porque caso ocorresse uma interrupção (<CTRL+C> ou <CTRL+\>) no script2, a linha só seria interpretada neste momento e o PID do script2 seria diferente do encontrado em /tmp/$$ (não esqueça que $$ é a variável que contém o PID do processo ativo);

• 2º Caso: O ftp acima encontra-se em script2
  Neste caso, o argumento do comando trap deveria estar entre apóstrofos ('), pois caso a interrupção se desse durante a execução de script1, o arquivo não teria sido criado, caso ocorresse durante a execução de script2, o valor de $$ seria o PID deste processo, que coincidiria com o de /tmp/$$.

O comando trap, quando executado sem argumentos, lista os sinais que estão sendo monitorados no ambiente, bem como a linha de comando que será executada quando tais sinais forem recebidos.

Se a linha de comandos do trap for nula (vazia), isto significa que os sinais especificados devem ser ignorados quando recebidos. Por exemplo, o comando:

    trap "" 2

Especifica que o sinal de interrupção (<CTRL+C>) deve ser ignorado. No caso citado, quando não se deseja que sua execução seja interrompida. No último exemplo note que o primeiro argumento deve ser especificado para que o sinal seja ignorado, e não é equivalente a escrever o seguinte, cuja finalidade é retornar o sinal 2 ao seu estado padrão (default):

    trap 2

Se você ignora um sinal, todos os Subshells irão ignorar este sinal. Portanto, se você especifica qual ação deve ser tomada quando receber um sinal, então todos os Subshells irão também tomar a ação quando receberem este sinal, ou seja, os sinais são automaticamente exportados. Para o sinal que temos mostrado (sinal 2), isto significa que os Subshells serão encerrados.

Suponha que você execute o comando:

    trap "" 2

e então execute um Subshell, que tornará a executar outro script como um Subshell. Se for gerado um sinal de interrupção, este não terá efeito nem sobre o Shell principal nem sobre os Subshell por ele chamados, já que todos eles ignorarão o sinal.

Outra forma de restaurar um sinal ao seu default é fazendo:

    trap - sinal

Em korn shell (ksh) não existe a opção -s do comando read para ler uma senha. O que costumamos fazer é usar o comando stty com a opção -echo que inibe a escrita na tela até que se encontre um stty echo para restaurar esta escrita. Então, se estivéssemos usando o interpretador ksh, a leitura da senha teria que ser feita da seguinte forma:

    echo -n "Senha: "
    stty -echo
    read Senha
    stty echo

O problema neste tipo de construção é que caso o operador não soubesse a senha, ele provavelmente daria um <CTRL+C> ou um <CTRL+\> durante a instrução read para descontinuar o programa e, caso ele agisse desta forma, o que quer que ele escrevesse, não apareceria na tela do seu terminal. Para evitar que isso aconteça, o melhor a fazer é:

    echo -n "Senha: "
    trap "stty echo
          exit" 2 3
    stty -echo
    read Senha
    stty echo
    trap 2 3

Para terminar este assunto, abra uma console gráfica e escreva no prompt de comando o seguinte:

Em seguida, pegue o mouse (arghh!!) e arraste-o de forma a variar o tamanho da janela corrente. Surpreso? É o Shell orientado a eventos...

Mais unzinho porque não pude resistir. Agora escreva assim:

Em seguida faça:

Você acabou de criar um subshell que irá dormir durante três segundos em background. Ao fim deste tempo, você receberá a mensagem já era, porque o sinal 17 é emitido a cada vez que um subshell termina a sua execução.

Para devolver estes sinais aos seus defaults, faça:

Ou

Acabamos de ver mais dois sinais que não são tão importante como os que vimos anteriormente, mas vou registrá-los na tabela a seguir:

Muito legal este comando, né? Se você descobrir algum caso bacana de uso de sinais, por favor me informe por e-mail porque é muito rara a literatura sobre o assunto.

Comando getopts

O comando getopts recupera as opções e seus argumentos de uma lista de parâmetros de acordo com a sintaxe POSIX.2, isto é, letras (ou números) após um sinal de menos (-) seguidas ou não de um argumento; no caso de somente letras (ou números) elas podem ser agrupadas. Você deve usar este comando para "fatiar" opções e argumento passados para o seu script.

Sintaxe:

    getopts cadeiadeopcoes nome

A cadeiadeopcoes deve explicitar uma cadeia de caracteres com todas as opções reconhecidas pelo script, assim se ele reconhece as opções -a -b e -c, cadeiadeopcoes deve ser abc. Se você deseja que uma opção seja seguida por um argumento, ponha dois-pontos (:) depois da letra, como em a:bc. Isto diz ao getopts que a opção -a tem a forma:

    -a argumento

Normalmente um ou mais espaços em branco separam o parâmetro da opção; no entanto, getopts também manipula parâmetros que vêm colados à opção como em:

    -aargumento

cadeiadeopcoes não pode conter interrogação (?).

O nome constante da linha de sintaxe acima, define uma variável que cada vez que o comando getopts for executado, receberá a próxima opção dos parâmetros posicionais e a colocará na variável nome.

getopts coloca uma interrogação (?) na variável definida em nome se achar uma opção não definida em cadeiadeopcoes ou se não achar o argumento esperado para uma determinada opção.

Como já sabemos, cada opção passada por uma linha de comandos tem um índice numérico, assim, a primeira opção estará contida em $1, a segunda em $2, e assim por diante. Quando o getopts obtém uma opção, ele armazena o índice do próximo parâmetro a ser processado na variável OPTIND.

Quando uma opção tem um argumento associado (indicado pelo : na cadeiadeopcoes), getopts armazena o argumento na variável OPTARG. Se uma opção não possui argumento ou o argumento esperado não foi encontrado, a variável OPTARG será "matada" (unset).

O comando encerra sua execução quando:

• Encontra um parâmetro que não começa por menos (-);
• O parâmetro especial -- marca o fim das opções;
• Quando encontra um erro (por exemplo, uma opção não reconhecida).

O exemplo abaixo é meramente didático, servindo para mostrar, em um pequeno fragmento de código o uso pleno do comando.

Para entendê-lo melhor, vamos executá-lo como está sugerido em seu cabeçalho:

Desta forma, sem ter muito trabalho, separei todas as opções com seus respectivos argumentos, deixando somente os parâmetros que foram passados pelo operador para posterior tratamento.

Repare que se tivéssemos escrito a linha de comando com o argumento (impressora) separado da opção (-P), o resultado seria exatamente o mesmo, exceto pelo $OPTIND, já que neste caso ele identifica um conjunto de três opções/argumentos e no anterior somente dois. Veja só:

Repare, no exemplo a seguir, que se passarmos uma opção inválida, a variável $OPT_LETRA receberá um ponto-de-interrogação (?) e a $OPTARG será "apagada" (unset).

- Me diz uma coisa: você não poderia ter usado um case para evitar o getopts?

- Poderia sim, mas para que? Os comandos estão aí para serem usados... O exemplo dado foi didático, mas imagine um programa que aceitasse muitas opções e seus parâmetros poderiam ou não estar colados às opções, suas opções também poderiam ou não estar coladas, ia ser um case infernal e com getopts é só seguir os passos acima.

- É... Vendo desta forma acho que você tem razão. É porque eu já estou meio cansado com tanta informação nova na minha cabeça. Vamos tomar a saideira ou você ainda quer explicar alguma particularidade do Shell?

- Nem um nem outro, eu também já cansei mas hoje não vou tomar a saideira porque estou indo dar aula na UniRIO, que é a primeira universidade federal que está preparando no uso de Software Livre, seus alunos do curso de graduação em informática.

Mas antes vou te deixar um problema para te encucar: quando você varia o tamanho de uma tela, no seu centro não aparece dinamicamente em vídeo reverso a quantidade de linhas e colunas? Então! Eu quero que você reproduza isso usando a linguagem Shell.

- Chico, traz rapidinho a minha conta! Vou contar até um e se você não trouxer eu me mando!

Vou aproveitar também para mandar o meu jabá: diga para os amigos que quem estiver afim de fazer um curso porreta de programação em Shell que mande um e-mail para a nossa gerencia de treinamento para informar-se.

Qualquer dúvida ou falta de companhia para um chope ou até para falar mal dos políticos é só mandar um e-mail para mim.

Valeu!