0 4 * * * /usr/russ/bin/autobkp.cron
Обратите внимание, что вход в cron вызывает управляющую процедуру
вместо того, чтобы непосредственно использовать autobkp. Имеется
несколько важных причин, чтобы написать процедуру на базе утилиты
autobkp. Во-первых, cron не печатает диагностическую информацию на ваш
терминал, поэтому если что-нибудь идет не так, вы никогда об этом не
узнаете. Во-вторых, проще поддерживать усеченную версию autobkp, а зву-
ковые предупреждения добавлять в управляющую процедуру. Вы можете сде-
лать собственные модификации управляющей программы и не беспокоиться об
отсутствии сообщений от самой утилиты. Управляющую программу можно
настолько усложнить, насколько вы желаете. Представленная здесь вполне
работоспособна, но легко может быть дополнена.
# Cron-driven autobkp driver
echo "backed up: `date`" > /dev/tty00
/usr/bin/autobkp < /usr/russ/bin/autobkpath
>> /usr/russ/bin/autobkp.log
Этот драйвер выдает сообщение на терминал, запускает autobkp,
использует для ввода файл со списком маршрутов в каталоге bin и помеща-
ет все выводные сообщения в файл протокола. Отметим, что имя терминала
дано как абсолютное (tty00). Это правильно только в том случае, когда в
вашей системе имеется такой терминал. Использование этого имени терми-
нала позволяет сообщению появиться на экране даже если никто на нем не
зарегистрирован. Это хорошо, потому что первое, что вы сможете увидеть
утром на вашем экране - это сообщение. Если у вас нет указанного терми-
нала, вы можете сделать что-то другое, например, передачу самому себе
почтового сообщения.
Примеры
1. $ autobkp
Запускает программу без передачи ей файла со списком маршрутов и
без файла протокола. Поскольку поля FROM, TO, TYPE ищутся в стандартном
вводе, введите их вручную. Когда вы нажмете возврат каретки, autobkp
выполнит указанные действия, напечатает информацию на экран терминала и
будет ожидать дальнейшего ввода. Для завершения выполнения командного
файла введите ^d (в результате оператор read вернется с ненулевым ста-
тусом).
2. $ autobkp < pathlist
Получает все входные данные из файла со списком маршрутов, но пе-
чатает всю протокольную информацию на экран терминала. Autobkp заверша-
ется, когда прочитает все данные в файле pathlist.
3. $ autobkp >> logfile
Как и в первом случае, списки маршрутов должны быть введены с кла-
виатуры. Все выходные данные выводятся в файл протокола, а не на экран.
Для завершения autobkp введите ^d.
4. $ autobkp -c < pathlist >> logfile
Копирует файлы из одной области жесткого диска в другую (опреде-
ленную каталогом-приемником в файле pathlist). Берет все входные данные
из файла pathlist и выводит все выходные данные в файл logfile.
Пояснения
Строки 4-8 выполняют проверку на наличие ошибок. Autobkp может
быть вызван либо без указания опций, либо с одной опцией (-c, при
использовании cp). Вспомните, что переназначение ввода-вывода НЕ прини-
мается во внимание при рассмотрении аргументов, потому что командный
процессор интерпретирует символы переназначения и то, что следует за
ними, до вызова команды. Таким образом, если количество позиционных па-
раметров больше одного (#1 -gt 1), получаем ошибочное условие. Затем
выдается сообщение об ошибке и синтаксическая подсказка и программа за-
вершается.
В строках 10-13 проверяется использование ключа -c. Обратите вни-
мание, что мы не проверяем, равен ли параметр $# единице и не пытаемся
выделить первый символ, чтобы посмотреть, равен ли он "-". Это потому,
что такая проверка приведет к ошибке, если не указан никакой ключ (что
является верным синтаксисом, как указывалось ранее).
Если мы сказали
if [ $1 = -c ]
и не указали ключей, то команда проверки не сработает и будет вы-
дано сообщение о том, что "no argument in the statement" ("в операторе
нет аргументов"). Но если мы выполним экранирование, например, так:
if [ "$1" = "-c" ]
то кавычки допускают нулевое значение аргумента, так что проверка
правильно оценит недостающее значение $1 как "равен ли нуль -c?" Это
даст результат "ложь", поэтому все хорошо.
Попутно давайте внимательно рассмотрим работу команды проверки. Вы
можете выполнить проверку значения двумя способами. Первый - сравнение
строк, а второй - числовое сравнение. Переменные командного процессора
ВСЕГДА хранятся в виде строк. Вы можете, тем не менее, заставить систе-
му рассматривать эти последовательности как числа и интерпретировать их
значения как числовые, подобно оператору number = val(STRING$) языка
Бейсик. Вы можете сказать системе, чтобы она изменила свой способ
рассмотрения символьных строк путем изменения синтаксиса операции срав-
нения. Для символьных строк сравнение выглядит так:
str1 = str2
а числовое сравнение выглядит так:
num1 -eq num2
-lt
-gt
Сверьте это с руководством. Если вы попытаетесь смешать символьное
сравнение с числовым, сравнение не будет работать. У меня забрало много
месяцев программирование на командном процессоре, пока наконец я заме-
тил это незначительное различие. Если не рассматривать подробно что-ли-
бо подобное, то такие технические ошибки кажутся неуловимыми, но можно
найти объяснения, почему что-нибудь работает не так.
Вернемся к возможности проверки кода. Если был передан ключ -c,
переменная COPY устанавливается, что значит "Да, мы собираемся копиро-
вать командой cp, а не использовать uucp". Если ключ -c не использу-
ется, переменная COPY не устанавливается.
В строках 15-16 печатается заголовочное сообщение о том, что будет
выполняться копирование. Обратите внимание, что мы спрятали команду
date системы UNIX внутри оператора echo, сократив число перехваченных
данных, которые мы должны иметь, чтобы получить дату непосредственно.
Проследите за кавычками в этом операторе. Внешние кавычки являются
двойными для того, чтобы упаковать весь аргумент для оператора echo.
Знаки ударения (`) обрамляют команду date так, что она является "выпол-
няемой внутри" и ее выходное сообщение перехватывается для наших нужд.
Одинарные кавычки внутри команды date используются для передачи форма-
та, который изменяет внешний вид значений так, чтобы заголовок выглядел
более красиво. В конце оператора echo кавычки следуют одна за другой.
Это не представляет проблемы, поскольку во вложенности нет никакой
двусмысленности. Вы должны помнить, что нужно следить за ситуацией,
когда вы и командный процессор можете расходиться во мнениях, т. е.,
когда вы должны обращаться к записи вида "\".
В строке 18 переменной SYSTEM присваивается имя удаленной системы,
в которую вы будете копировать командой uucp. Здесь она равна нулю, что
позже вызовет выполнение другой операции для обеспечения функционирова-
ния по умолчанию. Если же вы хотите всегда копировать на вполне опреде-
ленную систему, модифицируйте эту строку, чтобы назначить имя этой
системы. Если оставить строку 18 так, чтобы она назначала ноль, строка
14 поймает это значение и присвоит переменной SYSTEM имя вашей текущей
системы. Другими словами, если вы оставите строку 18 так, как она есть,
и вызовете autobkp без ключа -c, вы будете копировать командой uucp са-
ми на себя, что вполне допустимо. Однако, из соображений эффективности
вы, вероятно хотели бы выполнить autobkp -c для получения локальной ко-
пии.
Строка 19 иллюстрирует концепцию, часто используемую при програм-
мировании на командном языке. Давайте вкратце рассмотрим ее.
Первый символ - это ":". В данном случае мы интересуемся, что про-
исходит при проверке, а не возвращаемым значением, поэтому мы заставили
холостую команду ("не делать ничего") получать результат как аргумент.
Текст, следующий за двоеточием, интерпретируется так: "Если переменная
SYSTEM не установлена или установлена в ноль, присвоить ей значение,
которое следует за ней". В данном случае значение - это выход команды
uuname -l. Эта команда устанавливает, что система-приемник является той
же системой, что и исходная, если система-приемник не была прямо указа-
на ранее.
Мы используем uuname -l, а не стандартное выражение uname -n по
причине совместимости. Uname -n правильно получает имя узла из структу-
ры uts ядра операционной системы, но не все системы XENIX используют
элемент узла в виде структуры uts ядра системы. Вместо этого они посы-
лают имя в файл /etc/systemid, который соответствует микросети
(micnet), разработанной для XENIX фирмой Microsoft. Команда uuname -l -
это локальное имя (или исходная машина) для системы uucp. Эта команда
возвращает правильное значение и в UNIX, и в XENIX. Имеет смысл исполь-
зовать то, что всегда работает!
Строка 21 печатает имя исходной системы и системы-приемника. Это
сообщение добавляет информацию в запись о том, что собирается делать
autobkp, поэтому вы можете видеть по выходным данным, как вы установили
данный командный файл. Снова мы спрятали команду uuname внутри операто-
ра echo. У нас нет необходимости сохранять имя исходной системы,
поскольку оно нам всегда доступно при помощи команды uuname. Поскольку
мы всего два раза используем это имя, то решили не использовать для не-
го какую-либо переменную.
Строки 23-41 - это полный цикл, который управляет автоматическим
копированием. Управляющим циклом является оператор while, который чита-
ет значения из стандартного ввода. Заметьте, что вы можете считать
несколько значений в операторе read. Это удобно, если вы хотите читать
более одного значения, но не должны выделять каждую порцию входных дан-
ных для того, чтобы определить, является это первым, вторым или третьим
элементом данных. Мы читаем их все сразу и они присваиваются указанным
переменным. Поскольку выполняется чтение стандартного ввода, мы можем
перенаправить stdin при вызове autobkp и оператор read никогда не узна-
ет, чем они отличаются. Если мы не переназначаем входные данные, мы
должны вводить их с клавиатуры. Цикл завершается при чтении конца файла
- в данном случае конец файла со списком маршрутов или символа
control-d (^d) с клавиатуры. Поэтому управляющий цикл работает так:
"пока еще есть данные для чтения, читать их, обрабатывать, затем читать
следующие."
Строки 25-28 проверяют, является ли каталог-источник действительно
каталогом. Если нет, выдается сообщение об ошибке и оператор continue
приводит к следующей итерации цикла while.
В строке 30 производится смена каталога на каталог-источник. Вот
почему выходные данные команды find являются относительными к точке
