Hoje você monta uma estrutura de teste, aprende a técnica de segurança que evita apagar o que não devia, manipula dezenas de arquivos com um comando só, e termina usando os mesmos comandos dentro de um container.
Como a primeira parte da aula foi a N1 da 2ª etapa, sobra menos tempo de laboratório. Se não conseguir concluir todos os passos em aula, termine fora dela — este roteiro é suficiente pra você seguir sozinho, e as observações podem ser preenchidas depois.
Antes de manipular arquivos em lote, precisamos de arquivos para manipular — criados de forma controlada, para não haver risco.
mkdir -p ~/lab12/logs && cd ~/lab12 && touch relatorio{1..5}.txt sistema{1..3}.log notas.mdmkdir -p cria o diretório e os pais que faltarem. O {1..5} é expansão de chaves: o shell gera relatorio1.txt até relatorio5.txt automaticamente.
Já é um coringa em ação — nove arquivos criados com um comando só, em vez de nove touch separados.
O que esperar: nove arquivos e um diretório logs vazio. Trabalhe sempre dentro de ~/lab12 nos próximos passos — assim nenhum comando de hoje toca seus arquivos pessoais.
Este é o passo mais importante do roteiro. No shell não existe lixeira — o que você apaga, some. A defesa é sempre testar o padrão antes de usá-lo num comando destrutivo.
echo *.log e ls *.txtQuem expande o coringa é o shell, antes do comando rodar. Então echo mostra exatamente a lista que qualquer outro comando receberia.
É a diferença entre apagar o que você quis e apagar o que você não percebeu que casava com o padrão.
O que esperar: a lista expandida. Experimente também echo *, echo relatorio?.txt e echo *.{txt,md} pra ver como cada coringa se comporta.
echo nunca viu o coringa. O shell substituiu *.log pela lista de arquivos correspondentes antes de chamar o echo — que apenas imprimiu o que recebeu. É exatamente isso que acontece com rm, cp e todos os outros. Por isso testar com echo é seguro e confiável.
Agora sim — depois de confirmar o padrão no passo 2, use-o para valer.
mv *.log logs/ && ls logs/Move todos os arquivos .log de uma vez para o subdiretório logs/. O mesmo mv também renomeia, quando o destino é um nome de arquivo.
É a resposta da pergunta do slide: organizar dezenas ou centenas de arquivos num comando, não num por um.
O que esperar: os três .log agora dentro de logs/ e uma cópia completa em logs_backup/. Sem o -r no cp, copiar um diretório dá erro — teste e veja a mensagem.
Duas buscas diferentes: uma pelo nome do arquivo, outra pelo que está escrito dentro dele.
find ~/lab12 -name "*.log" e grep -rn "ERRO" ~/lab12find percorre a árvore de diretórios procurando pelo nome. grep -rn procura dentro dos arquivos, mostrando arquivo e número da linha.
"Onde está esse arquivo?" e "onde aparece essa mensagem de erro?" são duas perguntas distintas, com ferramentas distintas.
O que esperar: o find lista caminhos de arquivos; o grep -rn mostra arquivo:linha:conteúdo. Repare que o find encontrou também a cópia em logs_backup/, mas o grep só achou a mensagem onde ela realmente foi escrita.
echo "[ERRO] ..." > logs/sistema1.log antes — os arquivos criados com touch no passo 1 estão vazios. O grep diferencia maiúsculas de minúsculas por padrão; use grep -rni para ignorar essa diferença.
Os dois operadores de redirecionamento parecem quase iguais — e confundi-los é a causa clássica de "meu script apagou o log inteiro".
> versus >>> substitui todo o conteúdo do arquivo. >> acrescenta ao final, preservando o que já existia.
Todo script que grava log usa >>. Usar > por engano descarta silenciosamente todo o histórico anterior.
O que esperar: as duas primeiras linhas convivendo, e depois desaparecendo quando o > é usado. Rode você mesmo e veja o conteúdo sumir — é uma lição que se aprende melhor vendo.
Vocês já usaram docker exec no Encontro 5. Agora dá pra usar de forma interativa — abrindo um shell dentro do container e trabalhando lá.
docker run -d --name shelldemo alpine sleep 600 depois docker exec -it shelldemo sh-it significa interativo + terminal: em vez de rodar um comando e sair, você fica dentro do container, com um shell próprio.
É exatamente assim que se diagnostica um container quebrado em produção — entrando nele e usando os comandos básicos.
O que esperar: o prompt muda para / # — você está dentro do container. Os coringas funcionam igual. Note que a árvore de arquivos é outra: você não vê seu ~/lab12 ali, porque é um sistema de arquivos isolado. Digite exit para voltar.
alpine é mínima e não inclui o bash — só o sh, mais básico. É um bom lembrete de por que dominar os comandos essenciais importa: em imagens enxutas você não tem as ferramentas confortáveis à disposição, e não dá pra instalar nada no meio de um incidente.
Limpeza: ao sair, rode docker stop shelldemo && docker rm shelldemo.
"É melhor testar com echo antes de apagar."
"Quem expande o coringa é o shell, não o comando — quando rodei echo *.log, o echo recebeu a lista já pronta e nunca viu o asterisco. Como rm funciona exatamente do mesmo jeito, testar o padrão com echo ou ls antes mostra precisamente o que seria apagado. Sem lixeira no shell, essa checagem é a única defesa contra apagar um arquivo que casava com o padrão sem eu perceber."
Os passos 1–5 são os comandos básicos e de manipulação de arquivos do Laureano (p. 33–38 e 43–53). O passo 2 demonstra o papel do shell como interpretador descrito pelo Tanenbaum (p. 32–33): a expansão de coringas acontece no shell, antes de qualquer chamada de sistema — as mesmas chamadas que vocês rastrearam com strace no Encontro 3. O passo 5 retoma o redirecionamento de fluxos do Encontro 6, e o passo 6 é o gancho Docker do slide 10.
~/lab12echo antes de usá-losfind por nome e grep -rn por conteúdo> e >>docker exec -it e usei os comandos lá dentro