Come posso indurire gli script bash per non causare danni se cambiati in futuro?

Quindi, ho eliminato la mia cartella home (o, più precisamente, tutti i file a cui avevo accesso in scrittura). Quello che è successo è che ho avuto

build="build"
...
rm -rf "${build}/"*
...
<do other things with $build>

in uno script bash e, dopo non essere più necessario $build, rimuovendo la dichiarazione e tutti i suoi usi - ma il rm. Bash si espande felicemente a rm -rf /*. Sì.

Mi sono sentito stupido, ho installato il backup, ho rifatto il lavoro perso. Cercando di superare la vergogna.

Ora, mi chiedo: quali sono le tecniche per scrivere script bash in modo che tali errori non possano accadere, o almeno siano meno probabili? Ad esempio, avevo scritto

FileUtils.rm_rf("#{build}/*")

in una sceneggiatura di Ruby, l'interprete si sarebbe lamentato di buildnon essere stato dichiarato, quindi la lingua mi protegge.

Ciò che ho considerato in Bash, oltre al corraling rm(che, come menzionano molte risposte in domande correlate, non è problematico):

1. rm -rf "./${build}/"*
   Ciò avrebbe ucciso il mio lavoro attuale (un repository Git) ma nient'altro.
2. Una variante / parametrizzazione rmche richiede interazione quando agisce al di fuori della directory corrente. (Impossibile trovare.) Effetto simile.

È così, o ci sono altri modi per scrivere script bash che sono "robusti" in questo senso?

set -u

o

set -o nounset

Ciò renderebbe l'attuale shell trattare le espansioni di variabili non impostate come un errore:

$ unset build
$ set -u
$ rm -rf "$build"/*
bash: build: unbound variable

set -ue set -o nounsetsono opzioni di shell POSIX .

Un vuoto valore sarebbe non attivare un errore però.

Per quello, usa

$ rm -rf "${build:?Error, variable is empty or unset}"/*
bash: build: Error, variable is empty or unset

L'espansione di ${variable:?word}si espanderebbe al valore di a variablemeno che non sia vuota o non impostata. Se è vuoto o non impostato, wordverrà visualizzato in caso di errore standard e la shell tratterà l'espansione come un errore (il comando non verrebbe eseguito e, se eseguito in una shell non interattiva, terminerebbe). Se si lascia il campo :, l'errore si innescherebbe solo per un valore non impostato, proprio come sotto set -u.

${variable:?word}è un'espansione dei parametri POSIX .

Nessuno di questi avrebbe causato la chiusura di una shell interattiva a meno che set -e(o set -o errexit) non fosse attivo. ${variable:?word}provoca la chiusura degli script se la variabile è vuota o non impostata. set -ufarebbe uscire uno script se usato insieme a set -e.

Per quanto riguarda la tua seconda domanda. Non è possibile limitare il rmnon funzionamento al di fuori della directory corrente.

L'implementazione GNU di rmha --one-file-systemun'opzione che gli impedisce di eliminare in modo ricorsivo i filesystem montati, ma è il più vicino che credo che possiamo ottenere senza racchiudere la rmchiamata in una funzione che controlla effettivamente gli argomenti.

Come nota a margine: ${build}è esattamente equivalente a $buildmeno che l'espansione non avvenga come parte di una stringa in cui il carattere immediatamente successivo è un carattere valido in un nome di variabile, come in "${build}x".

Suggerirò i normali controlli di validazione usando test/[ ]

Saresti stato al sicuro se avessi scritto la tua sceneggiatura come tale:

build="build"
...
[ -n "${build}" ] || exit 1
rm -rf "${build}/"*
...

I [ -n "${build}" ]controlli che "${build}"sono una stringa di lunghezza diversa da zero .

Il ||è l'operatore logico OR in bash. Fa eseguire un altro comando se il primo fallisce.

In questo modo, era ${build}stato vuoto / indefinito / ecc. lo script sarebbe uscito (con un codice di ritorno 1, che è un errore generico).

Anche questo ti avrebbe protetto nel caso in cui hai rimosso tutti gli usi ${build}perché [ -n "" ]sarà sempre falso.

Il vantaggio di usare test/ [ ]è che ci sono molti altri controlli più significativi che può anche usare.

Per esempio:

[ -f FILE ] True if FILE exists and is a regular file.
[ -d FILE ] True if FILE exists and is a directory.
[ -O FILE ] True if FILE exists and is owned by the effective user ID.

Nel tuo caso specifico, in passato ho rielaborato la 'cancellazione' per spostare invece file / directory (supponendo che / tmp si trovi sulla stessa partizione della tua directory):

# mktemp -d is also a good, reliable choice
trashdir=/tmp/.trash-$USER/trash-`date`
mkdir -p "$trashdir"
...
mv "${build}"/* "$trashdir"
...

Dietro le quinte, questo sposta i riferimenti di file / dir di livello superiore dall'origine alle $trashdirstrutture di directory di destinazione tutte sulla stessa partizione e non passa il tempo a camminare sulla struttura di directory e a liberare i blocchi del disco per file proprio allora. Questo produce una pulizia molto più veloce mentre il sistema è in uso attivo, in cambio di un riavvio leggermente più lento (/ tmp viene pulito al riavvio).

In alternativa, una voce cron per pulire periodicamente /tmp/.trash-$USER manterrà / tmp dal riempimento, per i processi (ad esempio build) che consumano molto spazio su disco. Se la tua directory si trova su una partizione diversa come / tmp, puoi creare una directory simile / tmp-like sulla tua partizione e avere cron clean invece.

Ancora più importante, tuttavia, se si rovinano le variabili in qualche modo, è possibile ripristinare i contenuti prima che avvenga la pulizia.

Utilizzare la sostituzione del parametro bash per assegnare i valori predefiniti quando la variabile non è inizializzata, ad esempio:

rm -rf $ {variabile: - "/ inesistente"}

Cerco sempre di iniziare i miei script Bash con una riga #!/bin/bash -ue.

-esignifica "non riescono a prima uncathed e rror";

-usignifica "sicuro al primo utilizzo di u ndeclared variabile".

Scopri maggiori dettagli in un ottimo articolo Usa la modalità non ufficiale di Bash Strict (a meno che non ami il debugging) . Anche l'autore consiglia di utilizzare, set -o pipefail; IFS=$'\n\t'ma per i miei scopi questo è eccessivo.

Il consiglio generale per verificare se la variabile è impostata, è uno strumento utile per prevenire questo tipo di problema. Ma in questo caso c'era una soluzione più semplice.

Molto probabilmente non è necessario globare i contenuti della $builddirectory per eliminarli, ma non la $builddirectory stessa. Quindi, se salti l'estraneo, *un valore non impostato si trasformerebbe in quello rm -rf /che per impostazione predefinita la maggior parte delle implementazioni di rm nell'ultimo decennio rifiuterà di eseguire (a meno che tu non disabiliti questa protezione con l' --no-preserve-rootopzione GNU rm ).

Saltare la finale /così comporterebbe rm ''che risulterebbe nel messaggio di errore:

rm: can't remove '': No such file or directory

Funziona anche se il tuo comando rm non implementa la protezione per /.

Stai pensando in termini di linguaggio di programmazione, ma bash è un linguaggio di scripting :-) Quindi, usa un paradigma di istruzioni completamente diverso per un paradigma di linguaggio completamente diverso .

In questo caso:

rmdir ${build}

Poiché rmdirrifiuterà di rimuovere una directory non vuota, è necessario rimuovere prima i membri. Sai cosa sono quei membri, vero? Probabilmente sono parametri del tuo script o derivati ​​da un parametro, quindi:

rm -rf ${build}/${parameter}
rmdir ${build}

Ora, se inserisci altri file o directory come un file temporaneo o qualcosa che non avresti dovuto, rmdirgenererà un errore. Gestiscilo correttamente, quindi:

rmdir ${build} || build_dir_not_empty "${build}"

Questo modo di pensare mi è servito bene perché ... sì, ci sono stato, l'ho fatto.