Як я можу загартувати баш сценарії проти заподіяння шкоди при зміні в майбутньому?

Отже, я видалив свою домашню папку (або, точніше, всі файли, до яких я мав доступ для запису). Що сталося, що я мав

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

у bash-скрипті та, після того, як більше не потрібно $build, видаляючи декларацію та всі її звичаї - але, окрім rm. Баш щасливо розширюється до rm -rf /*. Так.

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

Тепер мені цікаво: що це за методи написання баш-скриптів, щоб подібні помилки не траплялися, або принаймні рідше? Наприклад, чи писав я

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

у сценарії Ruby, перекладач скаржився, що buildне оголошувався, тому мова мене захищає.

Що я розглянув у баші, окрім корралінгу rm(який, як згадується у багатьох відповідях у споріднених питаннях, не є проблематичним):

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

Це чи це, чи є інші способи написання баш-скриптів, які є "надійними" в цьому сенсі?

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відображатиметься на стандартній помилці, а оболонка розглядає розширення як помилку (команда не виконується, а якщо працює в неінтерактивній оболонці, це припиняється). Вихід із :поля призведе до помилки лише для невстановленого значення, як і під 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 очищається при перезавантаженнях).

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

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

Використовуйте підстановку bash paramater, щоб призначити значення за замовчуванням, коли змінна неініціалізована, наприклад:

rm -rf $ {змінна: - "/ неіснуюча"}

Я завжди намагаюся запускати свої сценарії Bash рядком #!/bin/bash -ue.

-eозначає "невдача при першому непошкодженому e rror";

-uозначає «провал на першому використанні з U ndeclared змінної».

Дізнайтеся більше деталей у чудовій статті Використовуйте суворий режим неофіційного Bash (якщо ви не любите налагодження) . Також автор рекомендує використовувати, set -o pipefail; IFS=$'\n\t'але для моїх цілей це надмірність.

Загальна порада перевірити, чи встановлена ​​ваша змінна - корисний інструмент для запобігання подібних проблем. Але в цьому випадку було більш просте рішення.

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

Пропуск /також слід, 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}"

Такий спосіб мислення мені добре послужив, тому що… так, це робив.