Barbosa

Trinta e oito anos depois da Copa do Mundo de 1950, um homem volta no tempo a fim de impedir o gol que derrotou o Brasil, destruiu seus sonhos de infância e acabou com a carreira do goleiro Barbosa.

Premiadíssimo curta de Jorge Furtado e Ana Luiza Azevedo, de 1988, unindo ficção científica e futebol de uma forma incrivelmente brasileira. Com Antônio Fagundes e Zé Vitor Castiel.

Para saber mais: CASACINEPOA

Assista aqui. Vale a pena!

Resolvendo Problemas Comuns 7 - open failed: |

Imagine um arquivo com algumas linhas duplicadas:

$ cat arquivo
permission denied
bad interpreter
missing separator
set correct localle
parameter list too long
unary operator expected
parameter list too long
bad interpreter

Obter as linhas distintas pode ser feito com a ajuda do sort + uniq

$ cat arquivo | sort | uniq
bad interpreter
missing separator
parameter list too long
permission denied
set correct localle
unary operator expected

- Puxa! Que ótima combinação! Vamos guarda-la?

Bom, podemos querer guardar este e outros comandos em uma variável de ambiente também, afinal, deve funcionar sem maiores problemas, certo?

$ CMD="sort | uniq"
$ cat arquivo | $CMD
sort: open failed: |: No such file or directory

- OPA! Eu sabia, maldito shell, encrenca com tudo!

Tsc... isso acontece porque o pipe | não foi informado como um 'pipe' e sim como a string "|" -- e o sort não conseguiu abrir o arquivo "|".
Este tipo de problema pode ser resolvido pelo eval -- ele interpreta novamente as strings na linha de comando.

$ eval "cat arquivo | $CMD"
bad interpreter
missing separator
parameter list too long
permission denied
set correct localle
unary operator expected

- Ah, agora funciona. Mas esse eval ai ficou feio...

Então vamos criar um alias para o comando!

$ alias cmd="sort | uniq"
$ cat arquivo | cmd
bad interpreter
missing separator
parameter list too long
permission denied
set correct localle
unary operator expected

Perceba que o comportamento do alias é diferente de uma variavel de ambiente. Devemos ficar atento à correta interpretação da nossa linha de comando pelo shell corrente, senão vamos ter resultados nem sempre amigáveis.

Ah, sim, o cat nesse exemplo é completamente supérfluo, poderia ser assim: 'sort arquivo | uniq'

- E o uniq precisa do sort ?

Sim... sem o sort ele fatalmente vai se perder, e é muito mais facil eliminar linhas repetidas que estejam em sequencia do que aleatórias. É bom dar uma lida no man destes comandos pois possuem opções muito poderosas!

Resolvendo Problemas Comuns 6 - unary operator expected

Uma desatenção, muito comum quando trabalhamos com variáveis de ambiente no shell é que, quando elas não foram setadas ainda, o shell expande elas para... nada.

$  [ $XALALA == "oi" ] && echo 'ok' || echo 'nok'
-bash: [: ==: unary operator expected
nok

Nesse caso o (resultado do) teste da variável até pode fazer sentido, porém troque o == por um != e veja o resultado. A solução é proteger a variável com aspas!

$  [ "$XALALA" != "oi" ] && echo 'ok' || echo 'nok'
ok

Simples e rápido!

Resolvendo Problemas Comuns 5 - The parameter list is too long

Essa é raro, mas acontece

$ cd /meu/diretorio
$ rm *.dll
Error: The parameter list is too long

- O que? Eu não posso apagar todos os meus 3459834574935734957 arquivos?

Bom, primeiro vamos analisar o que aconteceu: a linha de comando 'rm *.dll' é expandida pelo shell corrente a 'rm arquivo1.dll arquivo2.dll ... arquivoN.dll' e, nesse caso, esta lista de parâmetros foi demais pro probrezinho do rm.

Com o xargs é facil de resolver!

$ find /meu/diretorio -name '*.dll' -print | xargs rm

O que ele faz? o xargs recebe pela stdin toda uma lista de parâmetros que será entregue ao programa rm. Se esta lista extender o limite do sistema, então o xargs, inteligentemente, irá executar o rm uma vez, com a lista que for possível e, depois, executar de novo, até que todos os parâmetros sejam lidos. Aliás o xargs possui muitas opções interessantes, vale a pena dar uma estudada nele.

E assim todas as dll's são apagadas -- em definitivo, pois com rm 'tr00' não tem undelete ;-)

Resolvendo Problemas Comuns 4 - Corrigindo o localle

Precisamos estar atento que as variáveis de ambiente de localização podem atrapalhar, e muito, o comportamento de algumas expressões regulares.

Por exemplo, se eu quero encontrar uma palavra que começe com a e termine com o (ex: ação)

$ cat arquivo
luz, camera, ação
$ grep -oE 'a\w+o' arquivo    # nao mostra nada!

Antes de sair dizendo que o linux, grep ou as expressões regulares não prestam, vamos testar o mesmo comando no nosso 'idioma'

$ LC_ALL=pt_BR grep -oE 'a\w+o' arquivo
ação

Ahá! Agora vamos ver um exemplo mais interessante:

$ tr '[:lower:]' '[:upper:]' < arquivo
LUZ, CAMERA, AçãO
$ LC_ALL=pt_BR tr '[:lower:]' '[:upper:]' < arquivo
LUZ, CAMERA, AÇÃO

Perceberam como a variavel altera o comportamento das ERs?

Como ultima dica: sempre que precisarem comparar textos independente da 'caixa' (se maiúscula ou minúscula), usem os recursos de ignorecase da ferramenta utilizada. Converter um texto todo para minúscula pode não apenas ser afetado pela localização como existem idiomas onde alguns caracteres não tem o exato correspondente entre uma caixa e outra como nós pensamos -- é o caso do idioma Turco, onde o 'i' maiúsculo não é 'I'. E, principalmente, não tente fazer isso.

Mais informações em 'man locale' ;-)

Resolvendo Problemas Comuns 3 - missing separator

O make é um comando incrivelmente poderoso, principalmente para programadores, permitindo que tarefas sejam organizadas de acordo com dependências, por exemplo.

Um caso básico seria construir um grande programa, composto de diversos arquivos-fonte. O Makefile permite que vc compile apenas os arquivos que vc alterou desde o ultimo build, por exemplo, comparando o timestamp do fonte com o codigo objeto gerado.

Bom, ai um Makefile poderoso foi editado num editor de texto profissional e, na hora de testar, nos deparamos com:

$ make    
Makefile:3: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop.

$ cat Makefile   # nome padrão de arquivo para o make.
# um makefile comum
all:
        @echo "oi mundo"

Puxa, parece tudo certo... entretanto ai vai um pequeno detalhe: para cada target do makefile, os comandos que vem a seguir devem começar por um TAB (alias a mensagem de erro é bem clara nesse sentido, certo?). Vamos conferir:

$ cat -A Makefile   # é mais pontente que o -v
# um makefile comum$
all:$
        @echo "oi mundo"$

Tcharam! Se a linha do echo iniciasse com um TAB, como deveria ser, apareceria um ^I no inicio da linha. Provavelmente a origem disso é um editor de texto que transforma os TABS em 8 espaços por questões estéticas. Vamos corrigir o Makefile?

$ sed  -i 's/^\ \{8\}/\t/' Makefile
$ cat -A Makefile
# um makefile comum$
all:$
^I@echo "oi mundo"$
$ make
oi mundo

Pronto, basta substituir os espaços por TAB. Outra solução corrigir em um editor de textos mas sem a opção de expansão dos TABs -- no vim basta fazer

:set noexpandtab

e editar numa boa.

Resolvendo Problemas Comuns 1 - Permission denied

Não é incomum, quando não temos experiência em shell, passar por uma situação dessas:

$ ./script.sh
-bash: ./script.sh: Permission denied

Antes de sair olhando se há algo errado com o script, vamos analisar a mensagem de erro em pt_BR: Permissão negada. Diferente de outros sistemas operacionais, no mundo *nix o que faz de um arquivo um programa executável não é a sua extensão e sim as suas permissões.

Resumidamente, existem 3 permissões básicas quando se trata de arquivos: ler, escrever e (finalmente) executar (representado pelas letras r,w e x, respectivamente). Isto é o que impede um usuário de conseguir ler os documentos de outro, por exemplo. Então, um programa, para ser executado, precisa ter esta permissão correspondente, e ai entra o comando chmod.

$ ls -l script.sh
-rw-r--r--  1 peczenyj users 22 2007-07-26 11:08 script.sh
$ chmod +x script.sh  # vamos ativar o bit de execução (x)
$ ls -l script.sh
-rwxr-xr-x  1 peczenyj users 22 2007-07-26 11:08 ./script.sh
$ ./script.sh         #agora sim!!!
oi

Problema resolvido.

Resolvendo Problemas Comuns 2 - bad interpreter

Seguindo na nossa sessão de dicas, quem nunca passou por isso?

$ ./script.sh
: bad interpreter: No such file or directory

$ cat script.sh
#!/bin/bash
echo "oi"

- Hein? Mas está tudo certo, eu tenho um /bin/bash, o que está acontecendo?

Bom, vamos ver mais de perto:

$ cat -v script.sh  # 'show nonprinting'
#!/bin/bash^M
echo "oi"^M

Ahá! Tem um ^M no final das linhas atrapalhando.
- Mas o que é isso?
Muito provavelmente a origem desde script é uma maquina windows. A explicação é o caracter newline. O windows precisa de 2 caracteres para simbolizar o fim de uma linha em um arquivo texto puro, a dupla \r\n (veja link para a wikipedia), porém os *nix não precisam do \r -- que o cat gentilmente mostrou como um ^M. Este caracter a mais atrapalha o interpretador, que não recebe um /bin/bash e sim /bin/bash\r -- e isso realmente não existe.

Como resolver? Existem dois programas para este fim: unix2dos e dos2unix (as vezes aparecem como unixtodos e dostounix) que convertem os finais de linha em casos como este. Se vc abrir um arquivo texto do *nix em um bloco de texto vai ver todas as quebras de linha substituidas por um quadrado preto e todas as linhas em uma só.

Caso vc não tenha um programa conversor, pode usar o SED

$ sed -i 's/\r$//' script.sh
$ ./script.sh
oi

O tr também poderia ser usado, mas não é tão amigável.

$ tr -d '\r' < script.sh > novo_script.sh

Este detalhe pode ser muito importante um dia!

Tio Maneco

Quem se lembra do Tio Maneco?

Pois bem, descobri que foi aprovada a captação de recursos para a produção do filme "As aventuras de Reina Caiman em o resgate do Maneco" (RF Cinema e TV Ltda).

Pra mim, este é o filme mais esperado de todos os tempos, mal posso esperar para ver o Flávio Migliaccio de novo, em um dos papeis mais legais e inteligentes da tv brasileira -- afinal os filmes são impossiveis de serem achados e a série original foi apagada acidentalmente pela tv cultura.

(se alguem tiver mais informações, please, me avise!!!)

Calculando Números Primos usando Shell

Será possivel determinar se um número é primo, ou não, usando o bom e velho shell?

A resposta está no comando factor

seq 1 250 | factor | awk -F \: '$1 == $2{ print $1}' | column -x
2       3       5       7       11      13      17      19      23      29
31      37      41      43      47      53      59      61      67      71
73      79      83      89      97      101     103     107     109     113
127     131     137     139     149     151     157     163     167     173
179     181     191     193     197     199     211     223     227     229
233     239     241

A ideia é simples: se um número é primo ele possui apenas um único fator -- ele mesmo. Basta detectar esses casos via awk (ou grep, sed, existem varias formas). Usei aqui o seq para gerar uma seqüência e o column para tabular os resultados.