Дейв Тейлор - Сценарии командной оболочки. Linux, OS X и Unix. 2-е издание

#·· соответствующих заданному устройству TTY, пользователю или текущему

#·· пользователю.

if [! -z "$tty"]; then

··pids=$(ps cu −t $tty | awk "/ $1$/ { print \$2 }")

elif [! -z "$user"]; then

··pids=$(ps cu −U $user | awk "/ $1$/ { print \$2 }")

else

··pids=$(ps cu −U ${USER:-LOGNAME} | awk "/ $1$/ { print \$2 }")

fi

# Нет совпадений? Тогда все просто!

if [-z "$pids"]; then

··echo "$0: no processes match pattern $1" >&2

··exit 1

fi

for pid in $pids

do

··# Послать сигнал $signal процессу с идентификатором $pid: kill при этом

··#·· может вывести сообщение, если процесс уже завершился, если пользователь

··#·· не имеет прав завершить процесс и так далее, но это нормально. Свою

··#·· работу мы сделали.

··if [$donothing −eq 1]; then

····echo "kill $signal $pid" # Флаг −n: "показать и ничего больше не делать"

··else

····kill $signal $pid

··fi

done

exit 0

Так как этот сценарий выполняет агрессивную операцию и потенциально опасен, мы постарались минимизировать ложные совпадения с шаблоном, чтобы шаблон, например sh, не совпадал с такими строками в выводе ps, как bash или vi crashtest.c. Это достигается включением в шаблон префикса в команде awk ( , , ).

Добавление ведущего пробела перед шаблоном $1 и завершающего якорного метасимвола $ заставляет сценарий выполнять поиск в выводе команды ps не по шаблону 'sh', а по шаблону ' sh$'.

Этот сценарий имеет несколько начальных флагов, позволяющих управлять его поведением. Флаг −s SIGNAL позволяет указать сигнал, который должен посылаться найденному процессу или процессам вместо сигнала по умолчанию SIGINT. Флаги −u USER и −t TTY удобны в первую очередь для пользователя root, поскольку дают ему возможность послать сигнал всем процессам, связанным с указанным пользователем или устройством TTY соответственно. А флаг −n позволяет заставить сценарий вывести список найденных процессов без отправки любых сигналов. Наконец, должен быть указан шаблон для поиска процессов.

Теперь завершить все процессы csmount в OS X можно с помощью сценария killall, как показано в листинге 6.7.

Листинг 6.7.Завершение всех процессов csmount с помощью сценария killall

$./killall −n csmount

kill −INT 1292

kill −INT 1296

kill −INT 1306

kill −INT 1310

kill −INT 1318

Иногда при работе сценария возникает маловероятная, но возможная ошибка. Чтобы обеспечить более полное совпадение с заданным шаблоном, команда awk выводит идентификаторы только для процессов, имена которых содержат шаблон в конце, плюс ведущий пробел. Но теоретически возможна ситуация, когда в системе имеется два процесса: один с именем bash и другой с именем emulate bash. Если вызвать сценарий killall с шаблоном bash, оба процесса совпадут с ним, хотя только первое совпадение будет истинным. Решить эту проблему и обеспечить непротиворечивые результаты во всех системах очень непросто.

Если вы заинтересованы в этом, напишите на основе killall свой сценарий, который позволял бы изменять приоритет процессов с помощью команды renice по их именам, а не по числовым идентификаторам. В этом случае потребуется только вызвать renice вместо kill. Команда renice изменяет относительные приоритеты выполняющихся программ, позволяя, к примеру, уменьшать приоритет процесса, занимающегося передачей большого файла, и увеличивать приоритет видеоредактора, которым в данный момент пользуется начальник.

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

Однако формат определения заданий в cron довольно сложен: поля могут определяться как числа, диапазоны, множества и даже содержать мнемонические имена дней недели или месяцев. Хуже того, программа crontab выводит малопонятные сообщения об ошибках, когда встречает огрехи в системном или пользовательском файле с заданиями для планировщика cron.

Например, если допустить опечатку в названии дня недели, crontab выведет примерно такое сообщение об ошибке:

"/tmp/crontab.Dj7Tr4vw6R":9: bad day-of-week

crontab: errors in crontab file, can't install

Фактически в файле, вызывающем эту ошибку, есть вторая ошибка в строке 12, но crontab вынуждает нас пройти долгий путь, чтобы найти ее, из-за некачественной реализации кода, выполняющего проверку на наличие ошибок.

Вместо вылавливания ошибок способом, предлагаемым программой crontab, можно воспользоваться довольно длинным сценарием (в листинге 6.8), который просматривает файлы crontab, проверяет их синтаксис и убеждается, что все значения находятся в допустимых диапазонах. Одна из причин, почему такую проверку стоит реализовать в сценарии командной оболочки, заключается в возможности интерпретировать множества и диапазоны как отдельные значения. То есть для проверки значений, таких как 3-11 или 4, 6 и 9, достаточно проверить допустимость значений 3 и 11 для данного поля в первом случае, и значений 4, 6 и 9 во втором.

Листинг 6.8.Сценарий verifycron

··#!/bin/bash

··# verifycron — проверяет правильность оформления файла crontab.

··#·· За основу принята стандартная нотация cron: min hr dom mon dow CMD,

··#·· где min — числа 0-59, hr — числа 0-23, dom — числа 1-31,

··#·· mon — числа 1-12 (или названия) и dow — числа 0–7 (или названия).

··#·· Поля могут содержать диапазоны (a-e), списки значений, разделенных

··#·· запятыми (a,c,z), или звездочку. Обратите внимание, что форма определения

··#·· диапазона с шагом, допустимая в Vixie cron (например, 2–6/2),

··#·· не поддерживается текущей версией этого сценария.

··validNum()

··{

····# Возвращает 0, если аргумент содержит допустимое целое число,

····#·· и 1 — если нет. Функция принимает само число и максимально

····#·· возможное значение.

····num=$1·· max=$2

····# Для простоты звездочки в полях представляются символами "X",