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

По умолчанию bc имеет переменное значение для length, но, так как параметр scale по умолчанию получает нулевое значение, без параметров программа bc действует подобно синтаксической конструкции $(()). К счастью, если в вызов bc добавить параметр scale, она продемонстрирует огромную скрытую мощь, как показано в следующем примере, где вычисляется количество недель между 1962 и 2002 годами (исключая високосные дни):

$ bc

bc 1.06.95

Copyright 1991–1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation,

Inc.

This is free software with ABSOLUTELY NO WARRANTY.

For details type 'warranty’.

scale=10

(2002–1962)*365

14600

14600/7

2085.7142857142

quit

Чтобы получить доступ к возможностям bc из командной строки, сценарий-обертка должен удалить начальную информацию об авторских правах, если она имеется, однако большинство реализаций bc автоматически подавляют вывод начального баннера, если вводом является не терминал (stdin). Кроме того, сценарий-обертка определяет довольно разумное значение для масштаба (scale), передает программе bc фактическое выражение и затем завершает ее командой quit.

Чтобы запустить сценарий, передайте математическое выражение программе в виде аргумента, как показано в листинге 1.21.

Листинг 1.21.Тестирование сценария scriptbc

$ scriptbc 14600/7

2085.71

$ scriptbc −p 10 14600/7

2085.7142857142

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

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

while [-f $lockfile]; do

··sleep 1

done

touch $lockfile

Кажется, что такое решение должно работать. Или нет? Сценарий в цикле проверяет присутствие файла-блокировки и, как только он исчезает, тут же создает собственный, чтобы в безопасности изменить рабочий файл. Если в это время другой сценарий увидит файл-блокировку, то продолжит выполнять цикл ожидания, пока тот не исчезнет. Однако на практике такой способ не работает. Представьте, что сразу после выхода из цикла while, но перед вызовом команды touch диспетчер задач приостановит сценарий, дав возможность поработать другому сценарию.

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

К счастью, Стефан ван ден Берг (Stephen van den Berg) и Филип Гюнтер (Philip Guenther), авторы программы procmail для фильтрации электронной почты, также создали утилиту командной строки lockfile, которая дает возможность безопасной и надежной работы с файлами-блокировками в сценариях командной оболочки.

Многие реализации Unix, включая GNU/Linux и OS X, устанавливают утилиту lockfile по умолчанию. Ее присутствие в системе можно проверить простой командой man 1 lockfile. Если в результате откроется страница справочного руководства, значит, удача сопутствует вам! Сценарий в листинге 1.22 предполагает наличие команды lockfile, и все последующие сценарии требуют работоспособности механизма надежной блокировки, реализованного в сценарии № 10, поэтому перед их использованием также проверьте наличие команды lockfile в вашей системе.

Листинг 1.22.Сценарий filelock

··#!/bin/bash

··# filelock — Гибкий механизм блокировки файлов

··retries="10"·········· # Число попыток по умолчанию

··action="lock"··········# Действие по умолчанию

··nullcmd="’which true’" # Пустая команда для lockfile

··while getopts "lur: " opt; do

····case $opt in

······l) action="lock";;

······u) action="unlock";;

······r) retries="$OPTARG";;

····esac

··done

··shift $(($OPTIND — 1))

··if [$# −eq 0]; then # Вывести в stdout многострочное сообщение об ошибке.

····cat << EOF >&2

······Usage: $0 [-l|-u] [-r retries] LOCKFILE

······Where −l requests a lock (the default), −u requests an unlock, −r X

······specifies a max number of retries before it fails (default = $retries).

··EOF [2] Символы «EOF» должны находиться в начале строки, т. е. перед ними не должно быть пробелов. Это требование синтаксиса встроенных документов. В оригинале это правило нарушено. В данном листинге перед всеми строками добавлены 2 пробела, чтобы не нарушить отступы. Они к делу не относятся, и в данном случае считается, что метка EOF находится в начале строки, без отступа. — Примеч. пер .

····exit 1

··fi

··# Проверка наличия команды lockfile.

··if [-z "$(which lockfile | grep −v '^no ')"]; then

····echo "$0 failed: 'lockfile' utility not found in PATH." >&2

····exit 1

··fi

··if ["$action" = "lock"]; then

····if! lockfile -1 −r $retries "$1" 2> /dev/null; then

······echo "$0: Failed: Couldn't create lockfile in time." >&2

······exit 1

····fi

··else # Действие = разблокировка

····if [! -f "$1"]; then

······echo "$0: Warning: lockfile $1 doesn't exist to unlock." >&2

······exit 1

····fi

····rm −f "$1"

··fi

··exit 0

Как это часто бывает с хорошо написанными сценариями командной оболочки, половину листинга 1.22 занимает анализ входных данных и проверка на наличие ошибок. Затем выполняется инструкция if и осуществляется фактическая попытка использовать системную команду lockfile. Она вызывается с заданным числом попыток и генерирует собственное сообщение об ошибке, если ей так и не удалось заблокировать файл. А что произойдет, если предложить сценарию снять блокировку (например, удалить файл-блокировку), которой в действительности нет? В результате будет сгенерировано другое сообщение об ошибке. В противном случае lockfile просто удалит блокировку.