Глава 29. Отладка сценариев. Advanced Bash-Scripting Guide

Командная оболочка Bash не имеет своего отладчика, и не имеет даже каких либо отладочных команд или конструкций. [59] Синтаксические ошибки или опечатки часто вызывают сообщения об ошибках, которые которые практически никак не помогают при отладке.

Пример 29-1. Сценарий, содержащий ошибку

#!/bin/bash
# ex74.sh

# Этот сценарий содержит ошибку.

a=37

if [$a -gt 27 ]
then
  echo $a
fi  

exit 0

В результате исполнения этого сценария вы получите такое сообщение:

Пример 29-2. Пропущено ключевое слово

#!/bin/bash
# missing-keyword.sh:
# Какое сообщение об ошибке будет выведено, при попытке запустить этот сценарий?

for a in 1 2 3
do
  echo "$a"
# done     # Необходимое ключевое слово 'done' закомментировано.

exit 0

Сообщения об ошибках могут вообще не содержать номера строки, при исполнении которой эта ошибка появилась.

А что делать, если сценарий работает, но не так как ожидалось? Вот пример весьма распространенной логической ошибки.

Пример 29-3. test24

#!/bin/bash

#  Ожидается, что этот сценарий будет удалять в текущем каталоге
#+ все файлы, имена которых содержат пробелы.
#  Но он не работает.  Почему?


badname=`ls | grep ' '`

# echo "$badname"

rm "$badname"

exit 0

Попробуйте найти ошибку, раскомментарив строку echo "$badname". Инструкция echo очень полезна при отладке сценариев, она позволяет узнать -- действительно ли вы получаете то, что ожидали получить.

В данном конкретном случае, команда rm "$badname" не дает желаемого результата потому, что переменная $badname взята в кавычки. В результате, rm получает единственный аргумент (т.е. команда будет считать, что получила имя одного файла). Частично эта проблема может быть решена за счет удаления кавычек вокруг $badname и установки переменной $IFS так, чтобы она содержала только символ перевода строки, IFS=$'\n'. Однако, существует более простой способ выполнить эту задачу.

В общих чертах, ошибочными можно считать такие сценарии, которые

Инструменты, которые могут помочь при отладке неработающих сценариев

Установка ловушек на сигналы

trap

Определяет действие при получении сигнала; так же полезна при отладке.

Сигнал (signal) -- это просто сообщение, передается процессу либо ядром, либо другим процессом, чтобы побудить процесс выполнить какие либо действия (обычно -- завершить работу). Например, нажатие на Control-C, вызывает передачу сигнала SIGINT, исполняющейся программе.

trap '' 2
# Игнорировать прерывание 2 (Control-C), действие по сигналу не указано.

trap 'echo "Control-C disabled."' 2
# Сообщение при нажатии на Control-C.

Пример 29-5. Ловушка на выходе

#!/bin/bash

trap 'echo Список переменных --- a = $a  b = $b' EXIT
# EXIT -- это название сигнала, генерируемого при выходе из сценария.

a=39

b=36

exit 0
# Примечательно, что если закомментировать команду 'exit',
# то это никак не скажется на работе сценария,
# поскольку "выход" из сценария происходит в любом случае.

Пример 29-6. Удаление временного файла при нажатии на Control-C

#!/bin/bash
# logon.sh: Сценарий, написаный "на скорую руку", контролирует вход в режим on-line.

TRUE=1
LOGFILE=/var/log/messages
# Обратите внимание: $LOGFILE должен быть доступен на чтение (chmod 644 /var/log/messages).
TEMPFILE=temp.$$
# "Уникальное" имя для временного файла, где расширение в имени -- это pid процесса-сценария.
KEYWORD=address
# При входе, в файл /var/log/messages,
# добавляется строка "remote IP address xxx.xxx.xxx.xxx"
ONLINE=22
USER_INTERRUPT=13
CHECK_LINES=100
# Количество проверяемых строк.

trap 'rm -f $TEMPFILE; exit $USER_INTERRUPT' TERM INT
# Удалить временный файл, когда сценарий завершает работу по control-c.

echo

while [ $TRUE ] #Бесконечный цикл.
do
tail -$CHECK_LINES $LOGFILE> $TEMPFILE
# Последние 100 строк из системного журнала переписать во временный файл.
# Совершенно необходимо, т.к. новейшие версии ядер генерируют много сообщений при входе.
search=`grep $KEYWORD $TEMPFILE`
# Проверить наличие фразы "address",
# свидетельствующей об успешном входе.

if [ ! -z "$search" ] # Кавычки необходимы, т.к. переменная может содержать пробелы.
then
echo "On-line"
rm -f $TEMPFILE # Удалить временный файл.
exit $ONLINE
else
echo -n "." # ключ -n подавляет вывод символа перевода строки,
# так вы получите непрерывную строку точек.
fi

sleep 1
done

# Обратите внимание: если изменить содержимое переменной KEYWORD
# на "Exit", то сценарий может использоваться для контроля
# неожиданного выхода (logoff).

exit 0

# Nick Drage предложил альтернативный метод:

while true
do ifconfig ppp0 | grep UP 1> /dev/null && echo "соединение установлено" && exit 0
echo -n "." # Печать последовательности точек (.....), пока соединение не будет установлено.
sleep 2
done

# Проблема: Нажатия Control-C может оказаться недостаточным, чтобы завершить этот процесс.
# (Точки продолжают выводиться на экран.)
# Упражнение: Исправьте этот недостаток.

# Stephane Chazelas предложил еще одну альтернативу:

CHECK_INTERVAL=1

while ! tail -1 "$LOGFILE" | grep -q "$KEYWORD"
do echo -n .
sleep $CHECK_INTERVAL
done
echo "On-line"

# Упражнение: Найдите сильные и слабые стороны
# каждого из этих подходов.

Аргумент DEBUG, команды trap, заставляет сценарий выполнять указанное действие после выполнения каждой команды. Это можно использовать для трассировки переменных.

Пример 29-7. Трассировка переменной

#!/bin/bash

trap 'echo "VARIABLE-TRACE> $LINENO: \$variable = \"$variable\""' DEBUG
# Выводить значение переменной после исполнения каждой команды.

variable=29

echo "Переменная \"\$variable\" инициализирована числом $variable."

let "variable *= 3"
echo "Значение переменной \"\$variable\" увеличено в 3 раза."

# Конструкция "trap 'commands' DEBUG" может оказаться очень полезной
# при отладке больших и сложных скриптов,
# когда размещение множества инструкций "echo $variable"
# может потребовать достаточно большого времени.

# Спасибо Stephane Chazelas.

exit 0