[Перевод] Как писать bash-скрипты надежно и безопасно: минимальный шаблон18.11.2021 18:01

Располагая usage () где-то в начале скрипта, мы одним выстрелом убиваем двух зайцев:

1. Отображаем справочную информацию для пользователя, который хочет узнать все возможные и необходимые параметры для его запуска и не хочет изучать весь скрипт чтобы разобраться в них;

2. Имеем минимальную документацию на тот случай, когда кто-то будет вносить изменения в скрипт (например, даже вы сами две недели спустя, уже не помня, что и как было сделано).

   Я не утверждаю, что здесь нужно документировать каждую функцию. Но короткое красивое сообщение об использовании скрипта является обязательным минимумом.

Красивый вывод сообщений

setup_colors() {
  if [[ -t 2 ]] && [[ -z "${NO_COLOR-}" ]] && [[ "${TERM-}" != "dumb" ]]; then
    NOFORMAT='\033[0m' RED='\033[0;31m' GREEN='\033[0;32m' ORANGE='\033[0;33m' BLUE='\033[0;34m' PURPLE='\033[0;35m' CYAN='\033[0;36m' YELLOW='\033[1;33m'
  else
    NOFORMAT='' RED='' GREEN='' ORANGE='' BLUE='' PURPLE='' CYAN='' YELLOW=''
  fi
}

msg() {
  echo >&2 -e "${1-}"
}

Тут нужно отметить несколько вещей:

Во-первых, удалите функцию setup_colors (), если вы все равно не хотите использовать вывод разными цветами. Я оставил ее в скрипте просто потому, что лично я бы использовал цвета гораздо чаще, если бы не приходилось каждый раз гуглить их коды.

Во-вторых, эти цвета предназначены для использования только с моей функцией msg (), а не с командой echo.

Функция msg () предназначена для печати всего, что не является непосредственно выхлопом скрипта. Сюда входят все логи и сообщения, а не только ошибки.

Пример использования:

msg "This is a ${RED}very important${NOFORMAT} message, but not a script output value!"

Чтобы проверить, как он себя ведет, когда stderr не является интерактивным терминалом, добавьте в скрипт строку, подобную приведенной выше. Затем запустите его, перенаправив stderr на stdout и подключив его к cat. В результате операции конвейера вывод больше не отправляется непосредственно на терминал, а отправляется следующей команде, поэтому теперь вы не увидите цветов, но и не увидите никакого мусора:

Парсинг параметров

parse_params() {
  # default values of variables set from params
  flag=0
  param=''

  while :; do
    case "${1-}" in
    -h | --help) usage ;;
    -v | --verbose) set -x ;;
    --no-color) NO_COLOR=1 ;;
    -f | --flag) flag=1 ;; # example flag
    -p | --param) # example named parameter
      param="${2-}"
      shift
      ;;
    -?*) die "Unknown option: $1" ;;
    *) break ;;
    esac
    shift
  done

  args=("$@")

  # check required params and arguments
  [[ -z "${param-}" ]] && die "Missing required parameter: param"
  [[ ${#args[@]} -eq 0 ]] && die "Missing script arguments"

  return 0
}

Если имеет смысл вынести что-то в параметры скрипта, то я обычно делаю это. Даже если этот скрипт используется только в одном месте. Это упрощает его копирование и повторное использование, что случается рано или поздно. Кроме того, даже если что-то нужно захардкодить, то обычно для этого на уровне повыше есть место более подходящее, чем bash-скрипт.

Есть три основых типа параметров CLI: флаги, именнованные параметр и позиционные аргументы. Все они поддерживаются функцией parse_params ().

Единственный из распространенных видов параметров, который здесь не обрабатывается — это объединение нескольких однобуквенных флагов. Если вам нужно иметь возможность передавать два флага как -ab вместо -a -b, придется дописать немного кода.

Цикл while — это разбор параметров вручную. На любом другом языке вы бы использовали какой-нибудь встроенный парсер или библиотеку, но это Bash, поэтому как есть, так есть.

В шаблоне уже для примера объявлен флаг (-f) и именованный параметр (-p). Просто измените или скопируйте их, чтобы добавить другие параметры. И не забудьте после этого обновить usage () :)

Здесь есть важный момент, который обычно упускается, когда вы просто берете первый попавшийся результат запроса в гугл для парсинга аргументов Bash — это выдача ошибки при неизвестном параметре. Тот факт, что скрипт получил неизвестную опцию, означает, что пользователь либо ошибся, либо хотел, чтобы скрипт сделал что-то, что скрипт не может выполнить. Таким образом, ожидания пользователей и поведение скрипта могут быть совершенно разными. Лучше предотвратить это до того, как случится что-то плохое.

В Bash есть две альтернативы ручному парсингу параметров. Это 'getopt' и 'getopts'. Есть аргументы как за, так и против их использования. Я считаю эти функции не самым лучшим вариантом, поскольку по умолчанию 'getopt' в macOS ведет себя не так на других системах, а 'getopts' не поддерживает длинные параметры (например, --help).

Использование шаблона

Просто скопипасте его, как вы это делаете с большей частью кода, что вы находите в интернете.

После того, как вы его скопируете, вам нужно изменить только 4 вещи:

1. текст usage () с описанием скрипта;

2. содержимое cleanup ();

3. параметры в parse_params () — оставьте --help и --no-color, но замените -f и -p (это примеры)

4. основную логику скрипта :)

Переносимость

Я тестировал шаблон на MacOS (где по дефолту древний Bash 3.2) и нескольких образах Docker: Debian, Ubuntu, CentOS, Amazon Linux, Fedora. Всё работает.

Очевидно, что он не будет работать в средах без Bash, таких как Alpine Linux. Alpine, как минималистичная система, использует легковесный ash.

Вы можете спросить, не лучше ли использовать Bourne Shell-совместимый скрипт, который будет работать почти везде. Ответ, по крайней мере, в моем случае — нет. Bash безопаснее и мощнее (пусть не прост в использовании), поэтому я могу смириться с отсутствием поддержки нескольких дистрибутивов Linux, с которыми мне редко приходится иметь дело.

Внеклассное чтение

При создании скриптов CLI на Bash или другом лучшем языке существуют некоторые универсальные правила. Эти ресурсы расскажут, как сделать ваши небольшие скрипты и большие приложения с консольным интерфейсом надежными:

И в заключение

Я не первый и не последний, кто создал шаблон скрипта Bash. Хорошей альтернативой является этот проект, хоть он и слишком большой для моих повседневных нужд. В конце концов, я стараюсь делать bash-скрипты как можно компактнее.

При написании скриптов Bash используйте среду IDE, которая поддерживает линтер ShellCheck, например IDE JetBrains. Это не даст вам наворотить кучу вещей, которые могут привести к неприятным последствиям.

Мой шаблон Bash-скрипта также доступен как GitHub Gist (под лицензией MIT)

© Habrahabr.ru