#+ Когда последовательность команд становится слишком сложной,

#+ это повод к тому, чтобы поискать более короткий вариант.

if [ ! -e "/proc/$pidno/$PROCFILENAME" ]

# Пока работает процесс, файл "status" существует. then

echo "Соединение разорвано." fiexit $NOTCONNECTED

netstat -s | grep "packets received" # Получить некоторые сведения о соединении. netstat -s | grep "packets delivered"

sleep $INTERVAL echo; echo

done exit 0

#Как обычно, этот сценарий может быть остановлен комбинацией клавиш Control-C.

#Упражнение:

#----------

#Добавьте возможность завершения работы сценария, по нажатии на клавишу "q".

#Это сделает скрипт более жружественным к пользователю.

Будьте предельно осторожны при работе с файловой системой /proc, так как попытка записи в некоторые файлы может повредить файловую систему или привести к краху системы.

Глава 28. /dev/zero и /dev/null

/dev/null

Псевдоустройство /dev/null -- это, своего рода, "черная дыра" в системе. Это, пожалуй, самый близкий смысловой эквивалент. Все, что записывается в этот файл, "исчезает" навсегда. Попытки записи или чтения из этого файла не дают, ровным счетом, никакого результата. Тем не менее, псевдоустройство /dev/null вполне может пригодиться.

Подавление вывода на stdout.

cat $filename >/dev/null

# Содержимое файла $filename не появится на stdout.

Подавление вывода на stderr (from Пример 12-3).

316

Подавление вывода, как на stdout, так и на stderr.

Удаление содержимого файла, сохраняя, при этом, сам файл, со всеми его правами доступа (очистка файла) (из Пример 2-1 и Пример 2-2):

cat /dev/null > /var/log/messages

# : > /var/log/messages дает тот же эффект, но не порождает дочерний процесс. cat /dev/null > /var/log/wtmp

Автоматическая очистка содержимого системного журнала (logfile) (особенно хороша для борьбы с надоедливыми рекламными идентификационными файлами ("cookies")):

Пример 28-1. Удаление cookie-файлов

if [ -f ~/.netscape/cookies ] # Удалить, если имеются. then

firm -f ~/.netscape/cookies

ln -s /dev/null ~/.netscape/cookies

# Теперь, все cookie-файлы, вместо того, чтобы сохраняться на диске, будут "вылетать в трубу".

/dev/zero

Подобно псевдоустройству /dev/null, /dev/zero так же является псевдоустройством, с той лишь разницей, что содержит нули (здесь имеются ввиду двоичные нули, а не символы "0" ASCII). Информация, выводимая в этот файл, так же бесследно исчезает. Чтение нулей из этого файла может вызвать некоторые затруднения, однако это можно сделать, к примеру, с помощью команды od или шестнадцатиричного редактора. В основном, /dev/zero используется для создания заготовки файла с заданой длиной.

Пример 28-2. Создание файла подкачки (swapfile), с помощью /dev/zero

#!/bin/bash

#Создание файла подкачки.

#Этот сценарий должен запускаться с правами root.

317

if [ "$UID" -ne "$ROOT_UID" ] then

echo; echo "Этот сценарий должен запускаться с правами root."; echo fiexit $E_WRONG_USER

Еще одна область применения /dev/zero -- "очистка" специального файла заданного размера, например файлов, монтируемых как loopback-устройства (см. Пример 13-7) или для безопасного удаления файла (см. Пример 12-45).

Пример 28-3. Создание электронного диска

#!/bin/bash

# ramdisk.sh

318

#После перезагрузки, чтобы вновь создать электронный диск, запустите этот сценарий.

#Простое монтирование /mnt/ramdisk, без выполнения подготовительных действий, не будет работать.

exit 0

Глава 29. Отладка сценариев

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

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

#!/bin/bash

# ex74.sh

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

if [$a -gt 27 ] then

fiecho $a exit 0

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

./ex74.sh: [37: command not found

Что в этом сценарии может быть неправильно (подсказка: после ключевого слова if)?

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

На экране появится сообщение:

missing-keyword.sh: line 11: syntax error: unexpected end of file

319

Обратите внимание, сообщение об ошибке будет содержать номер не той строки, в которой возникла ошибка, а той, в которой Bash точно установил наличие ошибочной ситуации.

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

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

Пример 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'. Однако, существует более простой способ выполнить эту задачу.

#Правильный способ удаления файлов, в чьих именах содержатся пробелы. rm *\ *

rm *" "* rm *' '*

#Спасибо S.C.

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

1."сыплют" сообщениями о "синтаксических ошибках" или

2.запускаются, но работают не так как ожидалось (логические ошибки).

3.запускаются, делают то, что требуется, но имеют побочные эффекты (логическая бомба).

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

1.команда echo, в критических точках сценария, поможет отследить состояние переменных и отобразить ход исполнения.

320

2.команда-фильтр tee, которая поможет проверить процессы и потоки данных в критических местах.

3.ключи -n -v -x

sh -n scriptname -- проверит наличие синтаксических ошибок, не запуская сам сценарий. Того же эффекта можно добиться, вставив в сценарий команду set -n или set -o noexec. Обратите внимание, некоторые из синтаксических ошибок не могут быть выявлены таким способом.

sh -v scriptname -- выводит каждую команду прежде, чем она будет выполнена. Того же эффекта можно добиться, вставив в сценарий команду set -v или set -o verbose.

Ключи -n и -v могут употребляться совместно: sh -nv scriptname.

sh -x scriptname -- выводит, в краткой форме, результат исполнения каждой команды. Того же эффекта можно добиться, вставив в сценарий команду set -x или set -o xtrace.

Вставив в сценарий set -u или set -o nounset, вы будете получать сообщение об ошибке unbound variable всякий раз, когда будет производиться попытка обращения к необъявленной переменной.

4.Функция "assert", предназначенная для проверки переменных или условий, в критических точках сценария. (Эта идея заимствована из языка программирования C.)

Пример 29-4. Проверка условия с помощью функции "assert"

#!/bin/bash

# assert.sh

assert "$condition" $LINENO

# Сценарий продолжит работу только в том случае, если утверждение истинно.

# Прочие команды.

# ...

echo "Эта строка появится на экране только если утверждение истинно."

321

#...

#Прочие команды.

#...

exit 0

5.Ловушка на выхто в этом сценарии может быть неправильно (подсказка: после ключевого словоде.

Команда exit, в сценарии, порождает сигнал 0, по которому процесс завершает работу, т.е. -- сам сценарий. [60] Часто бывает полезным по выходу из сценария выдать "распечатку" переменных.

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

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

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

trap '' 2

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

trap 'echo "Control-C disabled."' 2

# Сообщение при нажатии на Control-C.

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

#!/bin/bash

# поскольку "выход" из сценария происходит в любом случае.

Пример 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"

322

ONLINE=22

USER_INTERRUPT=13

CHECK_LINES=100

# Количество проверяемых строк.

trap 'rm -f $TEMPFILE; exit $USER_INTERRUPT' TERM INT

# Удалить временный файл, когда сценарий завершает работу по control-c. echo

while [ $TRUE ] #Бесконечный цикл. dotail -$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 "."

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

323