Com base nos meus estudos introdutórios de Shell e da experiência de outras linguagens, notei que tinha algumas 'técnicas' pessoais para detectar erros, que foram apuradas pelo fato de não existir um debugger propriamente dito para Shell, como em outras linguagens.

Decidi aliar o que eu sabia e buscar mais algumas técnicas, em livros e no Google.

Mensagens de erro mais comuns

1. syntax error: unexpected end of file

• Ocorre quando criamos um laço ou condição, e não o 'fechamos', ou seja, não colocamos o 'done' ou 'fi' ao final. Ou seja, não estava esperando o final do arquivo. Interprete como: "Era pra ser outra coisa, não esqueceu de fechar nada no caminho?"

2. unexpected EOF while looking for matching `”’

• Quando esquecemos de completar as aspas ", ` ou ', aparece algo parecido. Nesse caso, ele não informa a linha. Então, se o código for muito grande, fica bem difícil de achar o erro. Um editor de texto com a opção highlighting ajuda bastante. Indico o vi/vim + plugin.

3. command not found

• Se viu isso, muito provavelmente digitou algo errado. Às vezes, é simplesmente um espaço que falta dentro de um 'if'. Por exemplo:
  • if[errado ]
  • if[ certo ]

Isso porque o '[' é um comando, é uma maneira mais simples do comando 'test' e ']' é um argumento pro comando '['.

Lembrando que, caso usemos uma variável, por exemplo: if[$a...]

. . .O shell apontará o erro, mas não como: [$a

. . .E sim usando o valor da variável. Por exemplo: se a=1, o erro será mostrado é: [1

O que pode vir a confundir um pouco.

Então, '[errado' = 'testerrado' , ou seja, você realmente digitou o comando de forma errada.

Interessante, não?

Alguns cuidados

Caso vá fazer script importantes, que não serão usados somente por você, tome algumas precauções:

1. Nem todos os sistemas vem com um compilador de C. Se vier, pode ser diferente, pode ser o GCC, CC ou LPICC, etc.
2. Há comandos que não são iguais em sistemas diferentes, como o ps, para listar os processos, que usamos as opções aux ou ef, dependendo do S.O..
3. Cuidado com os dispositivos. Pode se deparar com "/mnt/cdrom" ou "/media/cdrom".
4. Quando o Shell encontra o erro, ele morre, e o que vem em seguida não é rodado. Isso é um risco, pois se o que viria a seguir seriam ações que complementariam, remendariam ou concluiriam os comandos anteriores, pode acontecer de o sistema ficar instável ou inseguro.

Códigos de scripts

• exit ou read (e descubra): Em um script muito longo, é uma boa técnica inserir uns 'exit' no código. Caso o script rode bem, o erro estará depois do 'exit'.
  
  Se acontecer um bug, você sabe que até o 'exit' tem pelo menos um erro. Coloque sempre no meio do script. Depois no meio da metade que o erro está localizado... É o algoritmo de busca Binary Search.
  
  Podemos parar o script de uma forma menos agressiva. Em vez de sairmos, vamos dar uma pausa nele para simplesmente para fazer com que ele peça e leia uma variável do usuário. Se até então não tiver ocorrido erros, está OK nessa parte do script. Use 'echo's para situar-se.
  
  
• function: Se a dificuldade persistir, divida os blocos do script em funções e execute todas na ordem, como se o script estivesse rodando normalmente. O Shell deve acusar a função com erro.
• echo: Entupa o script de 'echos' do tipo "o comando tal passou", "o looping já era", "a condição não bugou", etc.

O mas próximo que podemos chegar de um debugging

Do artigo de Pipelines, vimos que cada comando tem sua saída de erros (stderr).

Ao invés de debuggar, podemos pedir pro Shell exibir mais informações à medida que ele analisa o script, através das opções '-n', '-v' e '-x'.

-n: Checa a sintaxe, sem executar os comandos do script:

$ sh -n nao_rode

Use sempre que necessitar de segurança.

-v: O 'v' é de verbose, é a mesma técnica de entupir o script com 'echo's.

Aqui, o Shell informa que comando vai rodar. Um por um:

$ sh -v fale_shell

Se você for rodar scripts de fontes duvidosas, uma boa prática é combinar esses dois comandos:

$ sh -nv sou_cauteloso

-t: Se estiver com problemas de valores de variáveis e quiser checar se elas estão se comportando (mudando) de maneira correta, use o 'execution trace', e vejo o traço de mudanças:

$ sh -t mude_e_mostre

Boas práticas

• Seja como o Unix.
• Pense como o Unix.
• Imite o Unix.
• Nomeie variáveis de modo a fazer sentido.
• Armazene endereços, de arquivos e diretórios, em variáveis. Assim evita a escrita repetida do endereço pelo script.
• Use parágrafos para separar trechos [ENTER].
• Idente loops e condições.
• Comente seus scripts, nem que seja só a primeira linha, dizendo pra que serve o script. Daqui há alguns meses você vai entender porquê isso é importante.
• Erros são tão comuns e 'importantes', que o Unix tem mensagem de erro até pra quando as coisas dão certo (?). Faça o mesmo. Forneça 'erros' bem escritos, explicativos e de maneira mais direta possível em seus scripts.
• A época das cavernas acabou. Não escreva seu código em forma de códigos (sacou?) incompreensíveis. Seja claro e simples, não use hieróglifos. Se for compartilhar, vale muito mais um código fácil de ler do quê um minimalista.
• Projetos grandes e complexos são feitos em partes pequenas e simples. A cada etapa de seu código, teste-o. Só vá para o próximo depois de testar completamente o trecho atual. Não deixe nada passar, ou vai virar uma bola de neve invisível.
• Escute Rush.

* Uma segunda opinião: Todos já passamos pela situação de ficar minutos, horas ou dias procurando o erro e tentamos suicídio quando descobrimos o quão bobo ele era.

É difícil achar erros em nossos códigos. Pra gente, o que estamos fazendo sempre faz sentido.

Simplesmente, peça para outra pessoa dar uma olhada.