Wie kann ich Bash-Skripte gegen zukünftige Änderungen schützen?

Also habe ich meinen Home-Ordner (oder genauer gesagt alle Dateien, auf die ich Schreibzugriff hatte) gelöscht. Was passiert ist, dass ich hatte

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

in einem Bash-Skript und nachdem Sie $builddie Deklaration und alle ihre Verwendungen nicht mehr benötigt haben , entfernen Sie sie - aber die rm. Bash dehnt sich glücklich aus rm -rf /*. Ja.

Ich fühlte mich dumm, habe das Backup installiert, die Arbeit, die ich verloren habe, überarbeitet. Der Versuch, die Schande hinter sich zu lassen.

Nun frage ich mich: Was sind Techniken, um Bash-Skripte so zu schreiben, dass solche Fehler nicht auftreten können oder zumindest weniger wahrscheinlich sind? Hatte ich zum Beispiel geschrieben

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

In einem Ruby-Skript hätte sich der Dolmetscher darüber beschwert, dass er buildnicht deklariert wurde, daher schützt mich die Sprache.

Was ich in bash außer dem Korralieren betrachtet habe rm(was, wie viele Antworten in verwandten Fragen erwähnen, nicht unproblematisch ist):

1. rm -rf "./${build}/"*
   Das hätte meine aktuelle Arbeit (ein Git-Repo) getötet, aber sonst nichts.
2. Eine Variante / Parametrisierung rmdavon erfordert Interaktion, wenn Sie außerhalb des aktuellen Verzeichnisses agieren. (Konnte keine finden.) Ähnliche Wirkung.

Ist es das oder gibt es andere Möglichkeiten, Bash-Skripte zu schreiben, die in diesem Sinne "robust" sind?

set -u

oder

set -o nounset

Dies würde die aktuelle Shell veranlassen, Erweiterungen nicht festgelegter Variablen als Fehler zu behandeln:

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

set -uund set -o nounsetsind POSIX-Shell-Optionen .

Ein leerer Wert würde jedoch keinen Fehler auslösen.

Verwenden Sie dazu

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

Die Erweiterung von ${variable:?word}würde sich auf den Wert von erweitern, es variablesei denn, sie ist leer oder nicht gesetzt. Wenn es leer oder nicht gesetzt ist, wird der wordStandardfehler angezeigt und die Shell behandelt die Erweiterung als Fehler (der Befehl wird nicht ausgeführt, und wenn er in einer nicht interaktiven Shell ausgeführt wird, wird dies beendet). Wenn Sie das :Feld verlassen, wird der Fehler nur für einen nicht festgelegten Wert ausgelöst, genau wie unter set -u.

${variable:?word}ist eine POSIX-Parametererweiterung .

Beides würde nicht dazu führen, dass eine interaktive Shell beendet wird, es sei denn, set -e(oder set -o errexit) ist ebenfalls in Kraft. ${variable:?word}Bewirkt, dass Skripte beendet werden, wenn die Variable leer oder nicht gesetzt ist. set -uwürde dazu führen, dass ein Skript beendet wird, wenn es zusammen mit verwendet wird set -e.

Wie für Ihre zweite Frage. Es gibt keine Möglichkeit, die rmArbeit außerhalb des aktuellen Verzeichnisses zu beschränken.

Die GNU-Implementierung von rmhat eine --one-file-systemOption, die das rekursive Löschen von gemounteten Dateisystemen verhindert, aber das ist so nah, wie wir glauben, ohne den rmAufruf in eine Funktion zu packen, die die Argumente tatsächlich prüft.

Als Randnotiz: ${build}Entspricht genau, $buildwenn die Erweiterung nicht als Teil einer Zeichenfolge erfolgt, bei der das unmittelbar folgende Zeichen ein gültiges Zeichen in einem Variablennamen ist, z. B. in "${build}x".

Ich werde normale Validierungsprüfungen mit test/ vorschlagen.[ ]

Sie wären in Sicherheit, wenn Sie Ihr Skript als solches geschrieben hätten:

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

Das [ -n "${build}" ]prüft, dass "${build}"eine Zeichenfolge ungleich Null ist .

Dies ||ist der logische ODER-Operator in der Bash. Wenn der erste Befehl fehlschlägt, wird ein anderer Befehl ausgeführt.

Auf diese Weise ${build}war leer / undefiniert / etc. Das Skript wurde beendet (mit dem Rückkehrcode 1, was ein allgemeiner Fehler ist).

Dies hätte Sie auch geschützt, falls Sie alle Verwendungen entfernt hätten, ${build}da dies [ -n "" ]immer falsch ist.

Der Vorteil der Verwendung von test/ [ ]besteht darin, dass es viele andere aussagekräftigere Prüfungen gibt, die es auch verwenden kann.

Zum Beispiel:

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

In Ihrem speziellen Fall habe ich in der Vergangenheit das Löschen überarbeitet, um stattdessen Dateien / Verzeichnisse zu verschieben (vorausgesetzt, / tmp befindet sich auf derselben Partition wie Ihr Verzeichnis):

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

Hinter den Kulissen werden dabei die Dateiverweise der obersten Ebene von den Quell- zu den Zielverzeichnisstrukturen $trashdirauf derselben Partition verschoben , und es wird keine Zeit darauf verwendet, die Verzeichnisstruktur zu durchsuchen und die Plattenblöcke pro Datei sofort freizugeben . Dies führt zu einer viel schnelleren Bereinigung, während das System aktiv ist, im Austausch für einen etwas langsameren Neustart (/ tmp wird beim Neustart bereinigt).

Alternativ verhindert ein Cron-Eintrag zum periodischen Bereinigen von /tmp/.trash-$USER, dass / tmp für Prozesse (z. B. Builds), die viel Speicherplatz verbrauchen, voll wird. Wenn sich Ihr Verzeichnis auf einer anderen Partition als / tmp befindet, können Sie ein ähnliches / tmp-ähnliches Verzeichnis auf Ihrer Partition erstellen und cron das stattdessen bereinigen lassen.

Am wichtigsten ist jedoch, dass Sie, wenn Sie die Variablen auf irgendeine Weise vermasseln, den Inhalt wiederherstellen können, bevor die Bereinigung stattfindet.

Verwenden Sie die Bash-Parameter-Ersetzung, um Standardeinstellungen zuzuweisen, wenn die Variable nicht initialisiert ist. Beispiel:

rm -rf $ {variable: - "/ nonexistent"}

Ich versuche immer, meine Bash-Skripte mit einer Linie zu beginnen #!/bin/bash -ue.

-eMittel „auf ersten uncathed versagen e rror“;

-ubedeutet „auf der ersten Nutzung nicht von u variable ndeclared“.

Weitere Details finden Sie in einem großartigen Artikel. Verwenden Sie den inoffiziellen Bash-Strict-Modus (es sei denn, Sie lieben das Debuggen) . Auch der Autor empfiehlt die Verwendung, set -o pipefail; IFS=$'\n\t'aber für meine Zwecke ist dies übertrieben.

Der allgemeine Rat, um zu überprüfen, ob Ihre Variable festgelegt ist, ist ein nützliches Werkzeug, um solche Probleme zu vermeiden. In diesem Fall gab es jedoch eine einfachere Lösung.

Es ist höchstwahrscheinlich nicht erforderlich, den Inhalt des $buildVerzeichnisses zu glätten , um sie zu löschen, nicht jedoch das eigentliche $buildVerzeichnis. Wenn Sie also das Fremde überspringen, wird *ein nicht festgelegter Wert rm -rf /angezeigt, zu dem sich die meisten RM-Implementierungen im letzten Jahrzehnt standardmäßig verweigern (es sei denn, Sie deaktivieren diesen Schutz mit der GNU RM- --no-preserve-rootOption).

Das Überspringen des Trailings /würde zu folgender rm ''Fehlermeldung führen:

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

Dies funktioniert auch dann, wenn Ihr Befehl rm keinen Schutz für implementiert /.

Sie denken in Programmiersprachen, aber bash ist eine Skriptsprache :-) Verwenden Sie also ein völlig anderes Anweisungsparadigma für ein völlig anderes Sprachparadigma .

In diesem Fall:

rmdir ${build}

Da rmdirdas Entfernen eines nicht leeren Verzeichnisses verweigert wird, müssen Sie zuerst die Mitglieder entfernen. Sie wissen, was diese Mitglieder sind, richtig? Sie sind wahrscheinlich Parameter für Ihr Skript oder von einem Parameter abgeleitet.

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

Wenn Sie nun einige andere Dateien oder Verzeichnisse wie eine temporäre Datei oder etwas, das Sie nicht haben sollten, dort ablegen, rmdirwird ein Fehler ausgegeben . Behandle es richtig, dann:

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

Diese Art zu denken hat mir gute Dienste geleistet, weil ... ja, ich war dort und habe das getan.