Как писать bash-скрипты надежно и безопасно: минимальный шаблон

Пришел к очень похожему скрипту, разве что вместо парсинга флагов в parse_params храню их в глобальном ассоциативном массиве, удобно когда единственный скрипт достаточно объемный и вмещает в себя множество слабосвязанных команд.

# Named args
declare -A args=()

#Positional args
args_r=()

parse_args() {
  local name
  local value
  local length

  while [ $# -gt 0 ]; do
    local arg="$1"
    shift

    if [[ "${arg}" != --* ]]; then
      args_r+=("${arg}")
      continue
    fi

    name="${arg%=*}"
    name="${name:2}"

    length=${#name}
    length=$((length+3))

    value="${arg:${length}}"
    if [ -z "${value}" ]; then
      value=true
    fi

    args["${name}"]="${value}"
  done

  readonly args
  readonly args_r
}

parse_args $@

script_dir=$(dirname "$(realpath $0)")

Я как-то таким пользовалься для определения директории скрипта, но не уверен, насколько оно универсально и/или надежно

Если вам нужно иметь возможность передавать два флага как -ab вместо -a -b, придется дописать немного кода

Например, прогнав параметры через getopt(1)

Можно ещё выносить повторяющиеся части скрипта и подключать их при необходимости. Например, если вынести setup_colors() и msg() в ~/.my_bash_lib/bash_setup_colors.sh, код будет выглядеть намного лаконичнее.

Добавляем необходимый функционал из библиотеки при необходимости:

. ~/.my_bash_lib/bash_setup_colors.sh

или

source ~/.my_bash_lib/bash_setup_colors.sh

и использовать

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

Преимущества и недостатки очевидны:

• + лаконичные скрипты, DRY

• + внёс изменения в библиотеку - применилось везде

• + очень удобно обслуживать (коллекционировать наработки, распространять и синхронизировать на платформах тем же git)

• - такие скрипты сами по себе не будут автономны, требуется библиотека

Не недостаток легко компенсируется... скриптом :) Легко реализовать механизм, позволяющий сделать скрипт автономным:

~/.my_bash_lib/bash_make_script_standalone script_using_my_lib.sh new_standalone_script.sh

Пытался в подобное, портабельный "вездеходный" скрипт для CI/CD, который должен работать на винде и маке разработчика, в любом дистрибутиве билд-агента, и в почти любом докер-образе. В итоге уперся в то, что помимо баша необходимо гарантировать наличие дополнительных пакетов для каждой более-менее серьезной задачи. Curl, jq, unzip... в итоге, вместо того чтобы везде таскать их, и сходить с ума от сложностей баш-скриптинга - плюнул и переписал все на python. При чем написать скрипт, который работает на py2 и py3 одновременно - вообще не проблема, буквально 3 if понадобилось. Зато теперь сплю спокойно.

На глазок, если "BASH_SOURCE[0]" заменить на "$0" и параметры не складывать в массив, то на ash тоже должно работать. ash — это часть busybox, который есть ещё в более каждом утюге, чем bash.

Почти никто не скажет "да, я люблю писать bash-скрипты",

Странно. Мне вот почему-то наоборот нравится BASH. Даже больше чем Python.

Мне пора проверять состояние психического здоровья, или ещё нет?

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

Например, ./script.sh -v -f 1 работает как ожидается, а ./script.sh -f 1 -v нет - логика verbose уже не применяется

Fix is welcome

Думаю, что для определения "домашнего" каталога скрипта цепочку dirname/realpath можно опустить и оставить только dirname.

Во многих своих скриптах я часто использу такое подобие шаблона. Некоторые определения могут отсутствовать. Кое-что добавляется в зависимости от задачи. Функции die/warn/catecho - для удобства вывода диагностических сообщений и аварийного прекращения.

#!/usr/bin/env bash

readonly ME="$( basename "$0" )"
readonly MYDIR="$( dirname "$0" )"

print_help() {
	cat - <<HELP
USAGE
    $ME [OPTIONS]

OPTIONS    
  bla-bla
HELP
}

main() {
	init
	parse_options "$@"

	# do payload	
}

init() {
	# preparations and initialization
	# set trap if needs
}

parse_options() {
	while [ $# -gt 0 ]
	do
		# parse CLI options
	done
}

# own functions' definitions doing the script payload

die() {
	warn "$@"
	exit 1
}

warn() {
	catecho "$@" >&2
}

catecho() {
	[ -t 0 ] && echo "$@" || cat -
}

main "$@"

realpath нужно если скрипт вызывается через симлинку, а надо подгружать что-то лежащее непосредственно рядом со скриптом.

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

Вот пример

$ cat /opt/scripts/test/z
#!/usr/bin/env bash

set -x

. "$( dirname "$0" )/z.sh"

blabla

$ cat /opt/scripts/test/z.sh
blabla() {
        echo "Hello! I am $FUNCNAME"
}

$ sudo ln -s /opt/scripts/test /test

$ /test/z
++ dirname /test/z
+ . /test/z.sh
+ blabla
+ echo 'Hello! I am blabla'
Hello! I am blabla

про catecho

Ваш вопрос заставил меня немного задуматься. И я вспомнил, откуда ноги растут у этой функции. Это кусок кода для логирования всего с разными уровнями (DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL). Не скажу, что в catecho сейчас есть большая нужда. Исторически так сложилось, что эта функция перетекает из одного скрипта в другой.

Вот небольшой фрагмент и несколько гипотетических примеров. Понятно, что echo "..." это просто заглушки для примеров, на самом деле - там какие-то внешние команды или функции. Первый пример, явно, избыточен - он легко перекрывается вторым, но первый виделся мне тогда и видится сейчас элегантнее, чем второй.

function logMsg()
{
	local level="$1"
	shift

	catecho "$@" \
	| sed "s|^|$(date '+%Y/%m/%d %H:%M:%S') ($$) ($level): |"
}

function warn()
{
	logMsg "WARNING" "$@"
}

echo "какая-то-команда неожиданно что-то напечатала" | warn
# DATE TIME (PID) (WARNING): какая-то-команда неожиданно что-то напечатала

warn "$( echo "какая-то-команда снова что-то напечатала" )"
# DATE TIME (PID) (WARNING): какая-то-команда снова что-то напечатала

warn "какие-то проблемы - надо что-то напечатать"
# DATE TIME (PID) (WARNING): какие-то проблемы - надо что-то напечатать

А как насчет обернуть весь скрипт в
( ... ) || exit $? && exit 0;
чтобы редактирование скрипта во время его выполнения не приводило к ошибкам?

Я баш знаю плохо, и читая сам скрипт, заметил что меня корёжит от закрытия скобки без её открытия в функции парсинга аргументов. Несколько раз пробежался по коду и всякий раз взгляд пытается найти ‘(‘ и не найдя ее вызывает тошноту. Блин кто это придумал? Неужели что-то типа такого нельзя было ->