Onde os comandos soltos do encontro passado viram uma ferramenta que trabalha por você — repetidamente, sem supervisão e sem erro humano.
Você digita, o shell executa, você lê o resultado e decide o próximo. Poderoso — mas exige você ali, presente.
Um arquivo com a sequência, mais variáveis, condições e repetição. Roda de madrugada, sem ninguém olhando.
Este encontro é a base direta do projeto final, que será lançado no próximo.
Ninguém acorda às 3h. E ninguém deveria precisar.
#!/bin/bash — diz ao SO qual interpretador usar para executar o arquivo.chmod +x script.sh — sem isso, o arquivo existe mas não roda.É só isso. Nada de compilar, nada de instalar. O shell que vocês já usam é o interpretador.
A sintaxe é enxuta e tem uma pegadinha que derruba todo iniciante: não pode haver espaço em volta do sinal de igual.
| Forma | Efeito |
|---|---|
| NOME="valor" | Correto — atribui o valor à variável |
| NOME = "valor" | Erro — o shell tenta executar um comando chamado NOME |
| echo $NOME | Usa o valor da variável |
| echo "${NOME}_backup" | Chaves delimitam o nome — necessário ao colar texto junto |
| DATA=$(date +%F) | Guarda a saída de um comando dentro da variável |
A última linha é a mais útil de todas: é assim que um script captura o resultado de um comando para decidir o que fazer com ele.
A estrutura if permite que o script reaja ao que encontrou — em vez de executar cegamente a mesma coisa sempre.
| Teste | Verifica |
|---|---|
| -f arquivo | O arquivo existe? |
| -d diretorio | O diretório existe? |
| -z "$VAR" | A variável está vazia? |
| "$A" -gt "$B" | A é maior que B? (números) |
Se uma variável estiver vazia ou contiver espaços, o shell a expande de forma inesperada e a condição quebra — ou pior, o comando age sobre o alvo errado.
if [ $NOME = "joao" ] — se $NOME estiver vazio, a linha vira if [ = "joao" ] e dá erro de sintaxe.
if [ "$NOME" = "joao" ] — mesmo vazia, vira if [ "" = "joao" ], que é falso e não quebra nada.
Vale para nomes de arquivo também: rm $ARQUIVO com espaços no nome apaga coisa errada; rm "$ARQUIVO" não.
Aqui o script finalmente supera o coringa do Encontro 12: em vez de aplicar um comando a muitos arquivos, ele aplica uma sequência inteira de decisões a cada um.
forArquivos de um diretório, uma faixa de números, itens de uma variável. É o laço mais usado em automação.
whileUsado para ler um arquivo linha a linha ou aguardar até que algo aconteça.
Combinado com if, o for resolve tarefas como "para cada log com mais de 7 dias, compacte e mova para o arquivo morto".
Quando o mesmo trecho aparece em vários pontos do script, vira função. O ganho não é só escrever menos — é ter um só lugar para corrigir quando algo mudar.
Dentro da função, $1 é o primeiro argumento recebido, $2 o segundo, e assim por diante — a mesma convenção que vale para os argumentos do próprio script.
Todo comando devolve um número ao terminar: 0 significa sucesso, qualquer outro valor significa erro. É assim que scripts encadeiam decisões de forma confiável.
| Construção | Significado |
|---|---|
| $? | Código de saída do último comando executado |
| cmd1 && cmd2 | Executa cmd2 só se cmd1 deu certo |
| cmd1 || cmd2 | Executa cmd2 só se cmd1 falhou |
| exit 1 | Encerra o script sinalizando erro a quem o chamou |
Vocês já usaram && desde o Encontro 5 sem saber que era isso — agora dá pra usar de propósito.
Um script pode orquestrar containers como orquestra qualquer outro comando — e é exatamente isso que o toolkit do projeto final vai fazer.
docker run, docker ps e docker stop dentro de um if — o script decide conforme o estado real.
O Dockerfile copia o script para dentro da imagem, como vocês já fizeram no Encontro 4.
No próximo encontro isso vira o projeto final: um toolkit de deploy, backup e monitoramento sobre container.
Variável, captura da saída de um comando, condição e alerta — tudo que vocês vão escrever hoje, num exemplo só.
Este script é essencialmente o que vocês vão construir passo a passo no roteiro de hoje.
Construção incremental: cada passo acrescenta uma peça ao mesmo script.
Um script que verifica se o container está no ar e o sobe se não estiver.
O roteiro de laboratório detalha os passos, com dicas se algo travar.
Atenção: nenhum dos dois livros-base cobre shell script. Por isso, nesta semana o próprio roteiro de laboratório é a leitura obrigatória — leia-o por inteiro, não só os comandos.
NEGUS & BRESNAHAN, Linux: a Bíblia (capítulo de shell scripts); MENDONÇA & ARAÚJO, Shell Linux. Para quem quiser se aprofundar além do roteiro.
O quiz da semana cobra o conteúdo do roteiro e recolhe suas observações da prática — tudo no mesmo instrumento.