Configurando dispositivos de saída em sistemas Unix-like
A confusão começa no shell. A maioria dos tutoriais ensina a lógica, mas não a parte chata que quebra no dia a dia. Falo de redirecionamento, permissões e da realidade de múltiplos fluxos rodando ao mesmo tempo. O conceito básico é simples: todo processo em um sistema POSIX abre três streams padrão – stdin (0), stdout (1) e stderr (2). A mágica acontece quando você precisa separá-los, especialmente quando um comando gera tanto saída normal quanto erros, e você quer salvar tudo em arquivos diferentes sem misturar as coisas.
O que são dispositivos de saída e por que eles importam
Dispositivos de saída são os alvos finais para os dados que seu programa gera. Pode ser um terminal, um arquivo, uma rede, ou até o lixo digital descartado para /dev/null. A definição técnica é rasa; o que importa é como eles se comportam quando você tenta fazer mais do que apenas exibir texto na tela. Eu já perdi horas porque um script de backup redirecionava stderr para o mesmo arquivo que stdout. O log ficava ilegível, erros críticos se perdiam no meio de mensagens normais. A solução não era complexa, mas a ausência de separação clara cria uma bagunça que leva tempo para depurar. Use a sintaxe 2>&1 com cuidado. Entenda a ordem.
Há um detalhe que quase ninguém menciona: o buffering. Saída padrão costuma ser bufferizada por linha quando vai para um terminal, mas torna-se bufferizada por bloco quando redirecionada para um arquivo. Isso significa que logs em tempo real podem aparecer com atraso, o que quebra monitoramento de processos longos. A flag --line-buffered em Python ou o uso de stdbuf resolvem, mas só se você souber que o problema existe.
Como redirecionar na prática
A sintaxe é minimalista, mas os erros são comuns. Veja um exemplo direto. Comando: find /var/log -name "*.log" -exec grep "erro" {} \; > saida.txt 2> erros.txt
👉 Clique no botão abaixo para saber mais sobre o assunto!
Isso separa o que encontra no arquivo de saída e o que falha no erro. Simples. Agora, se você quiser juntar ambos no mesmo arquivo, mas mantendo a capacidade de distinguir depois, use > log.txt 2>&1. A ordem importa porque o shell avalia da esquerda para a direita. 2>&1 copia o descritor 2 para o mesmo lugar que 1 já aponta. Eu tive um caso recente com um script rsync que gerava kilobytes de saída de status e alguns erros de permissão. Redirecionei tudo para um arquivo de log único usando &>. Funcionou, mas o log cresceu 4 GB em uma semana porque erros de conexão eram frequentes e não havia filtragem. A lição: não jogue tudo no mesmo lugar sem um plano de rotação ou limpeza. Configure logrotate desde o início, mesmo para scripts pequenos.
Outro ponto: dispositivos de saída não são sempre arquivos. Você pode direcionar para um socket TCP com /dev/tcp/host/port em bash, ou para um FIFOnamed pipe. Isso permite pipelines customizados sem processos intermediários. Um erro comum é criar um FIFO e esquecer de fechá-lo, travando o leitor. Sempre gerencie o ciclo de vida do pipe no script.
Armazenamento e limites
Não adianta ter a configuração perfeita se o disco enche. Verifique disponibilidade com df -h antes de rodar comandos pesados. Em servidores, o logrotate deve estar configurado para qualquer arquivo de saída que cresça previsivelmente. Um script que não gerencia seu próprio log é uma bomba-relógio. Se estiver lidando com saída de rede, pense em latência e perda de pacotes. Dados enviados via TCP podem serACKed sem garantia de chegada imediata. Para debugging, use UDP em portas locais quando a integridade absoluta não for crítica, mas espere retransmissões e ordens diferentes. Isso não é bug, é protocolo.
Resumo sem frescura
Dispositivos de saída são fundamentais para qualquer trabalho sério com linha de comando. Domine o redirecionamento, entenda buffering, planeje a retenção de logs desde o início. Teste em ambientes controlados antes de depender deles em produção. O resto é só prática.
