Jak mogę wzmocnić skrypty bash przed spowodowaniem szkody, gdy zostaną zmienione w przyszłości?

Tak więc usunąłem mój folder domowy (a ściślej wszystkie pliki, do których miałem dostęp do zapisu). Stało się to, że miałem

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

w skrypcie bash i, po nieużywaniu $build, usuwając deklarację i wszystkie jej zastosowania - ale rm. Bash z radością się rozwija rm -rf /*. Tak.

Czułam się głupio, zainstalowałam kopię zapasową, przerobiłam utraconą pracę. Próbuję przejść obok wstydu.

Zastanawiam się: jakie są techniki pisania skryptów bash, aby takie błędy nie mogły się zdarzyć, a przynajmniej były mniej prawdopodobne? Na przykład, gdybym napisał

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

w skrypcie Rubiego tłumacz narzekałby, że buildnie został zadeklarowany, więc język mnie chroni.

To, co rozważałem w bashu, oprócz korygowania rm(które, jak wspomina wiele odpowiedzi w powiązanych pytaniach, nie jest bezproblemowe):

1. rm -rf "./${build}/"*
   To zabiłoby moją obecną pracę (repozytorium Git), ale nic więcej.
2. Wariant / parametryzacja rmtego wymaga interakcji, gdy działa poza bieżącym katalogiem. (Nie można znaleźć żadnego.) Podobny efekt.

Czy to jest, czy istnieją inne sposoby pisania skryptów bash, które są „solidne” w tym sensie?

set -u

lub

set -o nounset

Spowodowałoby to, że bieżąca powłoka traktowałaby ekspansje zmiennych nieustalonych jako błąd:

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

set -ui set -o nounsetsą opcjami powłoki POSIX .

Pusta wartość to nie wywoła błędu chociaż.

W tym celu użyj

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

Rozwinięcie ${variable:?word}spowoduje rozwinięcie do wartości, variablechyba że jest puste lub nieuzbrojone. Jeśli jest pusty lub rozbrojony, wordzostanie wyświetlony przy standardowym błędzie, a powłoka potraktuje rozszerzenie jako błąd (polecenie nie zostanie wykonane, a jeśli uruchomione w powłoce nieinteraktywnej, zostanie zakończone). Pozostawienie :wyjścia spowodowałoby błąd tylko dla wartości nieustawionej, tak jak poniżej set -u.

${variable:?word}jest rozszerzeniem parametru POSIX .

Żadne z nich nie spowodowałoby zakończenia interaktywnej powłoki, chyba że set -e(lub set -o errexit) również działało. ${variable:?word}powoduje zamknięcie skryptów, jeśli zmienna jest pusta lub nieuzbrojona. set -uspowodowałoby zamknięcie skryptu, gdyby był używany razem z set -e.

Co do twojego drugiego pytania. Nie ma możliwości ograniczenia, rmaby nie działać poza bieżącym katalogiem.

Implementacja GNU rmma --one-file-systemopcję, która powstrzymuje go przed rekurencyjnym usuwaniem zamontowanych systemów plików, ale jest to tak blisko, jak uważam, że możemy uzyskać bez zawijania rmwywołania w funkcji, która faktycznie sprawdza argumenty.

Na marginesie: ${build}jest dokładnie równoważny, $buildchyba że rozwinięcie następuje jako część ciągu, w którym znak następujący bezpośrednio jest poprawnym znakiem w nazwie zmiennej, na przykład w "${build}x".

Mam zamiar zasugerować normalne sprawdzanie poprawności za pomocą test/[ ]

Byłbyś bezpieczny, gdybyś napisał swój skrypt jako taki:

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

Te [ -n "${build}" ]kontrole to "${build}"jest długość łańcucha niezerowe .

Jest ||to logiczny operator OR w bash. Powoduje uruchomienie innej komendy, jeśli pierwsza nie powiodła się.

W ten sposób ${build}były puste / niezdefiniowane / itp. skrypt zostałby zakończony (z kodem powrotu 1, co jest błędem ogólnym).

To również ochroniłoby cię na wypadek, gdybyś usunął wszystkie zastosowania, ${build}ponieważ [ -n "" ]zawsze będzie to fałsz.

Zaletą używania test/ [ ]jest to, że istnieje wiele innych bardziej znaczących kontroli, których może również używać.

Na przykład:

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

W twoim konkretnym przypadku w przeszłości przerabiałem „usuwanie”, aby zamiast tego przenosić pliki / katalogi (zakładając, że / tmp znajduje się na tej samej partycji co katalog):

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

Za kulisami przenosi referencje do plików / $trashdirkatalogów najwyższego poziomu ze źródeł do struktur katalogów docelowych na tej samej partycji i nie spędza czasu na chodzeniu po strukturze katalogów i zwalnianiu bloków dyskowych dla poszczególnych plików. Powoduje to znacznie szybsze czyszczenie, gdy system jest w użyciu, w zamian za nieco wolniejszy restart (/ tmp jest czyszczony przy ponownym uruchomieniu).

Alternatywnie, wpis crona do okresowego czyszczenia /tmp/.trash-$USER powstrzyma / tmp przed zapełnieniem, dla procesów (np. Kompilacji), które zajmują dużo miejsca na dysku. Jeśli twój katalog znajduje się na innej partycji jako / tmp, możesz utworzyć podobny katalog / tmp na swojej partycji i zamiast tego mieć cron clean.

Najważniejsze jest jednak, że jeśli w jakikolwiek sposób spieprzysz zmienne, możesz odzyskać zawartość przed czyszczeniem.

Użyj podstawienia parametrów bash, aby przypisać wartości domyślne, gdy zmienne są niezainicjowane, np .:

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

Zawsze staram się zaczynać skrypty Bash od linii #!/bin/bash -ue.

-eoznacza „niepowodzenie przy pierwszym niepowodzeniu e rrr ”;

-uoznacza „nie na pierwszym użyciu u ndeclared zmienną”.

Znajdź więcej szczegółów w świetnym artykule Użyj nieoficjalnego trybu ścisłego bash (chyba, że ​​debugujesz Looove) . Również autor zaleca używanie, set -o pipefail; IFS=$'\n\t'ale dla moich celów jest to przesada.

Ogólna rada, aby sprawdzić, czy twoja zmienna jest ustawiona, jest przydatnym narzędziem do zapobiegania tego rodzaju problemom. Ale w tym przypadku było prostsze rozwiązanie.

Najprawdopodobniej nie ma potrzeby globalizowania zawartości $buildkatalogu, aby je usunąć, ale nie samego $buildkatalogu. Więc jeśli pominąłeś to, co obce, *wówczas nieustawiona wartość zamieniłaby się w rm -rf /, że domyślnie większość implementacji rm w ostatniej dekadzie odmówiłaby wykonania (chyba że wyłączysz tę ochronę za pomocą opcji GNU rm --no-preserve-root).

Omijając końcowego znaku /, jak również skutkowałoby rm ''która spowodowałaby komunikat o błędzie:

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

Działa to nawet jeśli twoje polecenie rm nie implementuje ochrony /.

Myślisz w kategoriach języka programowania, ale bash jest językiem skryptowym :-) Więc zastosuj zupełnie inny paradygmat instrukcji dla zupełnie innego paradygmatu języka .

W tym przypadku:

rmdir ${build}

Ponieważ rmdirodmówi usunięcia niepustego katalogu, musisz najpierw usunąć członków. Wiesz, kim są ci członkowie, prawda? Prawdopodobnie są to parametry twojego skryptu lub pochodzą z parametru, więc:

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

Teraz, jeśli umieścisz tam inne pliki lub katalogi, takie jak plik tymczasowy lub coś, czego nie rmdirpowinieneś mieć , spowoduje to błąd. Postępuj właściwie, a następnie:

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

Ten sposób myślenia mi dobrze służył, ponieważ ... tak, byłem tam, zrobiłem to.