Функции логирования из BASH-скриптов

man logger

Это вы уж сами как-нибудь, logger Вам в руки.

А чем оно по сути будет отличаться от сислога?

Тем, что информативные по существу сообщения пишутся сразу в нужный файл лога. И почему будет? Вроде, уже есть. Как бэкенд можно, наверное, и logger юзать в будущих версиях. Кстати, нет ли у Вас желания реализовать соотв. функциональность?

exec >/log/file 2>&1

Всегда было достаточно.

Всегда было достаточно

Пока Вы делаете exec, я уже пишу info_ 'Про уровни логирования не забывайте, и занимать потоки STDOUT и STDERR - не есть хорошо'.

Не есть хорошо, потому что логирование в файл не имеет никакого отношения к потокам вывода и ошибок.

Пока Вы делаете exec, я уже

…дошли до слова «логирования»?

занимать потоки STDOUT и STDERR - не есть хорошо

Ага, куда ж без дупликации-то.

потому что логирование в файл не имеет никакого отношения к потокам вывода и ошибок.

Если вам не нужен выхлоп того, что скрипт выполняет, значит, там всё хорошо работает и давно отлажено. Тогда сам собой напрашивается вопрос, что там вообще логировать и зачем.

dev-libs/log4sh ?

там всё хорошо работает и давно отлажено

Вот именно это мне интересно видеть воочию, дабы спать спокойно. Или иметь веский повод обеспокоиться. Программы, которые хорошо отлажены как правило перестают работать как только условия начинают отличаться от тех, в которых их отлаживали. Вот и получается, что если у вас в кармане нет личного тестировщика, то нужно хотя бы чётко понимать, что делала программа прежде, чем перешла в состояние shit happens.

Посмотрел. Ужаснулся. Информации в логе меньше, код, предшествующий logger_info «Message» вымораживает мозг напрочь. Кажется, принцип KISS им неведом, это печально.

Ещё можно к сообщениям указывать источник ($0, $BASH_LINENO, $BASH_COMMAND) или даже порядок вызова функций:

function debug() {
  if [ X"$DEBUG" == X"true" ]; then
    local dbgmsg="$@"
    local funcstack="${FUNCNAME[*]}"
    funcstack=$(echo "$funcstack" | sed 's/^debug //' | tac -s ' ' \
                                  | xargs | sed 's/ /()->/g' )
    [ "$funcstack" ] && funcstack="${funcstack}()"
    errmsg "DEBUG: $funcstack: $dbgmsg"
  fi
}

Результат:

# export DEBUG=true
# hwswa/hwswa.sh
DEBUG: main()->read_config(): CONFIGFILE=/home/me/WORK/work/Projects/AutoHWCheck/hwswa/hwswa.conf
Waiting for checks to be finished
DEBUG: main()->a_ssh(): SERVER=LOCAL COMMAND=echo OK
DEBUG: main()->a_ssh()->read_server(): SERVER=LOCAL
DEBUG: main()->a_ssh(): SERVER=LOCAL COMMAND=mktemp -d -p `pwd` hwswa-scripts.XXXXX
DEBUG: main()->a_ssh()->read_server(): SERVER=LOCAL
DEBUG: main()->a_scp(): SERVER=LOCAL LOCAL_FILE=/home/me/WORK/work/Projects/AutoHWCheck/hwswa/remote-scripts/. REMOTE_FILE=/home/test/hwswa-scripts.SvMIM/
DEBUG: main()->a_scp()->read_server(): SERVER=LOCAL
DEBUG: main()->a_scp(): SERVER=LOCAL LOCAL_FILE=/home/me/WORK/work/Projects/AutoHWCheck/hwswa/config/networks REMOTE_FILE=/home/test/hwswa-scripts.SvMIM/networks

Там, по-моему, чисто механический перенос из log4j, со всеми последствиями. Какие уж там принципы.
Кстати, другим поделием этой Кати - shunit2, я пользоваться не смог - функциональность только та, что легко перетащилась из junit (а для sh этого мало), зато недостатки портированы в полном объёме.
Так что я эту штуку упомянул просто для полноты картины.

В этом что-то есть: на уровне отладки DEBUG нужно больше информации. С другой стороны, в каком случае нужен стек вызова функций и прочее подобное... Думаю, в обработчике какого-нибудь сигнала, того же HUP, пригодится: в ответ на отправку сигнала скрипт подробно пишет в лог, что он делает.

Нет. На самом деле не вижу особой необходимости в логгерах для баш-скриптов. logger свою задачу вполне выполняет.

А для ПО, если не хватает сислога, предпочитаю всякие Log4* в зависимости от языка.

Не поверишь, BASH-скрипты иногда вполне себе тоже ПО.