Как я могу защитить bash-скрипты от нанесения вреда при их изменении в будущем?

Итак, я удалил свою домашнюю папку (или, точнее, все файлы, к которым у меня был доступ для записи). Что случилось то, что у меня было

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

в bash-скрипте и, после того, как больше не нужно $build, удалить объявление и все его использования - кроме rm. Баш радостно расширяется rm -rf /*. Да.

Я почувствовал себя глупо, установил резервную копию, переделал потерянную работу. Пытаясь пройти мимо позора.

Теперь я задаюсь вопросом: каковы методы написания сценариев bash, чтобы такие ошибки не возникали или, по крайней мере, менее вероятны? Например, если бы я написал

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

в сценарии на Ruby переводчик жаловался на то, что его buildне объявили, поэтому язык защищает меня.

То, что я рассмотрел в bash, помимо загона rm(что, как упоминают многие ответы в смежных вопросах, не является проблемой):

1. rm -rf "./${build}/"*
   Это убило бы мою текущую работу (репозиторий Git), но ничего больше.
2. Вариант / параметризация rmэтого требует взаимодействия при работе вне текущего каталога. (Не удалось найти.) Подобный эффект.

Это так или есть другие способы написания bash-скриптов, которые в этом смысле «надежны»?

set -u

или же

set -o nounset

Это заставит текущую оболочку рассматривать расширения неустановленных переменных как ошибку:

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

set -uи set -o nounsetявляются параметрами оболочки POSIX .

Пустое значение будет не вызовет ошибку , хотя.

Для этого используйте

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

Расширение ${variable:?word}будет расширяться до значения, variableесли оно не пусто или не установлено. Если он пуст или не установлен, при wordстандартной ошибке будет отображаться символ, и оболочка будет рассматривать расширение как ошибку (команда не будет выполнена, и если она выполняется в неинтерактивной оболочке, это завершится). Выход из :out приведет к ошибке только для неустановленного значения, как показано ниже set -u.

${variable:?word}является расширение параметр POSIX .

Ни один из них не приведет к завершению интерактивной оболочки, если set -e(или set -o errexit) также не действует. ${variable:?word}заставляет сценарии завершиться, если переменная пуста или не установлена. set -uприведет к завершению работы сценария, если используется вместе с set -e.

Что касается вашего второго вопроса. Нет способа ограничить rmне работать за пределами текущего каталога.

В реализации GNU rmесть --one-file-systemопция, которая останавливает рекурсивное удаление смонтированных файловых систем, но это настолько близко, насколько я думаю, мы можем получить, не заключая rmвызов в функцию, которая фактически проверяет аргументы.

Как примечание стороны: ${build}точно эквивалентно, $buildесли только расширение не происходит как часть строки, где непосредственно следующий символ является допустимым символом в имени переменной, например, в "${build}x".

Я собираюсь предложить нормальные проверки с использованием test/[ ]

Вы были бы в безопасности, если бы написали свой сценарий так:

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

В [ -n "${build}" ]проверяет, "${build}"является ненулевой длиной строкой .

||Является логическим ИЛИ оператор в ударе. Это вызывает выполнение другой команды, если первая не удалась.

Таким образом, ${build}был пустой / неопределенный / и т. Д. скрипт завершился бы (с кодом возврата 1, что является общей ошибкой).

Это также защитило бы вас, если бы вы удалили все варианты использования, ${build}потому [ -n "" ]что всегда будут ложными.

Преимущество использования test/ [ ]состоит в том, что есть много других более значимых проверок, которые он также может использовать.

Например:

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

В вашем конкретном случае я переработал «удаление» в прошлом, чтобы вместо этого переместить файлы / каталоги (предполагая, что / tmp находится в том же разделе, что и ваш каталог):

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

За кулисами это перемещает ссылки верхнего уровня на файлы / $trashdirкаталоги из источника в структуры каталогов назначения на одном и том же разделе, и не тратит время на обход структуры каталогов и освобождение дисковых блоков для каждого файла. Это приводит к гораздо более быстрой очистке, когда система активно используется, в обмен на немного более медленную перезагрузку (/ tmp очищается при перезагрузках).

В качестве альтернативы, запись cron для периодической очистки /tmp/.trash-$USER будет препятствовать заполнению / tmp для процессов (например, сборок), которые занимают много дискового пространства. Если ваш каталог находится в другом разделе как / tmp, вы можете создать аналогичный / tmp-подобный каталог в вашем разделе и использовать вместо этого cron.

Но самое главное, что если вы облажаете переменные каким-либо образом, вы можете восстановить содержимое до того, как произойдет очистка.

Используйте замену параметра bash, чтобы назначить значения по умолчанию, когда переменная неинициализирована, например:

rm -rf $ {переменная: - "/ несуществующая"}

Я всегда стараюсь начинать свои скрипты Bash со строки #!/bin/bash -ue.

-eозначает «провал на первом uncathed е rror»;

-uозначает «провал на первом использовании из U ndeclared переменной».

Более подробную информацию можно найти в большой статье. Используйте неофициальный строгий режим Bash (если вы не любите отладку) . Также автор рекомендует использовать, set -o pipefail; IFS=$'\n\t'но для моих целей это излишне.

Общий совет, чтобы проверить, установлена ​​ли ваша переменная, является полезным инструментом для предотвращения такого рода проблем. Но в этом случае было более простое решение.

Скорее всего, нет необходимости перемещать содержимое $buildкаталога, чтобы удалить его, но не сам $buildкаталог. Таким образом, если вы пропустили постороннее, *то получится неустановленное значение, rm -rf /которое по умолчанию большинство реализаций rm за последнее десятилетие откажется выполнять (если вы не отключите эту защиту с помощью --no-preserve-rootопции GNU rm ).

Пропуск трейлинга /также приведет rm ''к появлению сообщения об ошибке:

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

Это работает, даже если ваша команда rm не реализует защиту для /.

Вы думаете с точки зрения языка программирования, но bash - это язык сценариев :-) Итак, используйте совершенно другую парадигму инструкций для совершенно другой языковой парадигмы.

В этом случае:

rmdir ${build}

Так rmdirкак откажется удалить непустую директорию, сначала нужно удалить участников. Вы знаете, что это за члены, верно? Они, вероятно, являются параметрами вашего сценария или получены из параметра, поэтому:

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

Теперь, если вы поместите туда какие-нибудь другие файлы или каталоги, например временный файл или что-то, чего не должно быть, вы получите rmdirошибку. Обращайтесь с этим правильно, тогда:

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

Такой образ мышления хорошо послужил мне, потому что ... да, был там, сделал это.