ра экранированы, т.е. впереди них стоят символы наклонной черты. Ко-
мандный интерпретатор shell воспринимает кавычки вокруг строки поиска
на первой фазе синтаксического разбора без отмены присвоения, тем са-
мым оставляя двойные кавычки последующей команде find.
Если опцией является что-либо другое, выводится сообщение об
ошибке и программа завершается.
В строке 27 выводится сообщение о том, какой файл содержит ре-
зультаты работы. Сам этот оператор не создает файл. Он только печатает
имя файла, который будет создан позже.
Строки 29-43 - это главный цикл всей программы. Оператор find
должен быть повторно проанализирован командой eval, поскольку перемен-
ная NAME содержит нужные нам данные. Если бы не было команды eval, то
подстановка символьных строк выполнялась бы неправильно. Обратите вни-
мание, что переменной NAME не требуются кавычки в строке 24. Они уже
есть в переменной NAME, так как были обработаны командой eval.
Оператор find находит только файлы типа f, или обычные файлы,
т.е. не каталоги и не символьные или блочные устройства. Здесь под
"обычными файлами" понимается, что они еще могут быть файлами данных
или исполняемыми. Если значение переменной NAME равно нулю, оно не
влияет на командную строку. Если NAME содержит символы файлов прог-
раммной разработки, то они становятся частью команды find при выполне-
нии команды eval. Это накладывает ограничения на шаблон поиска команды
find. Когда файлы найдены, их имена выводятся в стандартный вывод.
Стандартный вывод по конвейеру передается команде sort, располагающей
имена файлов по порядку. Это сильно помогает при сортировке горы вы-
водной информации. Чтение кипы распечаток толщиной в один фут может
свести с ума кого угодно.
Отсортированные имена по конвейеру передаются в цикл while, кото-
рый читает имена файлов по одному. Обратите внимание, что стандартный
вывод для всего цикла while переадресовывается во временный файл, что
облегчает сборку всех выходных результатов в одном месте вместо пере-
адресации каждого вызова команды в файл.
Для каждого подходящего файла выполняется проверка в строках
31-36. Проверка начинается с запуска команды file. Выход file по кон-
вейеру передается команде egrep, которая ищет тип файла, соответствую-
щий набору нескольких выражений. Если какое-либо выражение подходит,
то нам не нужно обрабатывать этот файл. Это не текстовый файл, и его
нельзя вывести на принтер. Во многих случаях файлы данных содержат
большое количество символов прогона формата, которые выталкивают стра-
ницу после каждой пары символов. Если вы не будете находиться рядом с
принтером, когда печатаются такие файлы, то вы можете получить
листинг, занимающий половину ящика бумаги, затратив целый лес на не-
нужную работу.
Нам не нужен выход команды egrep, а только ее статус возврата.
Если egrep обнаруживает одно из указанных ей выражений, она заверша-
ется со статусом успеха, или 0. Тем самым проверка if включает выпол-
нение оператора then, который в данном случае выводит нас из конструк-
ции if-then-else и продолжает цикл while, пропуская таким образом
файл.
Если же egrep не обнаружила ни одну из указанных символьных
строк, то выполнение продолжается с оператора else, который выполняет
еще одну команду file и переадресовывает ее вывод на устройство с име-
нем /dev/tty. Это универсальное имя устройства, которое гарантирует
вам вывод на экран вашего терминала. UNIX обеспечивает, что указание
/dev/tty обходит любые команды переадресации вывода, действующие в
данный момент. Поскольку стандартный вывод уже переадресован для всего
цикла while, то нам нужно попасть на устройство /dev/tty, чтобы вывод
шел на экран терминала, а не в файл печати. Отображение на терминал
имени обрабатываемого файла позволяет пользователю знать, какой файл
будет добавлен к распечатке.
Если файл удовлетворяет нашим критериям, он обрабатывается коман-
дой pr. Результат направляется в стандартный вывод, который переад-
ресован циклом while так, чтобы результат четко попадал в один файл.
Отметим, что нам нужно поставить символ добавления в файл вывода (>>).
В противном случае мы получим запись на место существующего файла пе-
чати, а значит в файле печати будет находиться только последний обра-
ботанный файл.
После того как все файлы обработаны, задается вопрос о том, хоти-
те ли вы вывести результирующий файл на печать. Предлагается ответить
на этот вопрос "да" (yes) или "нет" (no), однако в программе проверя-
ется только положительный ответ (yes). Это значит, что нажатие любой
клавиши трактуется как ответ "no", кроме клавиши "y", означающей "да".
Ответ пользователя читается с клавиатуры, и проверяется, является ли
он символом "y". Если да, то файл ставится в очередь на печать. Если
нет, дальнейшая проверка не производится и командный файл завершается.
Отметим, что запрос о выводе на печать поступил в стандартный вы-
вод. Переадресация вывода действовала только во время работы цикла
while, а затем прекратилась. Так было сделано потому, что цикл while
был фактически еще одним порожденным shell-процессом (subshell) и пе-
реадресация действовала только в этом те внимание, что маршрутная-
установите значения переменных вне цикла, а затем измените их внутри
цикла. После завершения цикла переменные по-прежнему имеют свои перво-
начальные значения, а не измененные в цикле значения. Измененные зна-
чения касались переменных порожденного интерпретатора shell, которые
исчезли, когда порожденный shell завершился. Переменные интерпретатора
shell могут передавать значения только вниз, порожденным процессам, но
процессы-потомки не могут передавать значения переменных вверх, роди-
тельскому процессу. Обычно передача значений переменных поддерживается
при помощи какого-либо файла, в котором хранятся данные для обмена
между родительским процессом и процессом-потомком.
УПРАВЛЕНИЕ ВЫВОДНЫМИ ФАЙЛАМИ БОЛЬШИХ РАЗМЕРОВ
Как мы уже отмечали, общий размер выводного файла ограничен. На-
помним, что команда find проходит все дерево каталогов вниз до конца
по всем поддеревьям, начиная с каталога, имя которого указано в ко-
мандной строке. Если вы находитесь на вершине очень глубокого дерева,
то обрабатываться могут буквально сотни файлов. Поскольку вы ограниче-
ны максимальным размером выводного файла, вы можете обработать только
ограниченное число файлов. Конечно, количество файлов, которое вы мо-
жете обработать, зависит также от того, насколько велики входные фай-
лы.
Если выводной файл достигает своего максимума, все добавляемые
после этого данные теряются. Потеря данных весьма болезненна, и обычно
требуется некоторое время, чтобы ее обнаружить. В медленно работающей
системе попытка обработать большое дерево, например все исходные
тексты системы UNIX, может занять целый час и даже больше, прежде чем
выходной файл заполнится. Это означает, что вы должны находиться рядом
и следить за тем, когда файл переполнится. Если он все-таки перепол-
нился, вы должны все выбросить и начать сначала. Это также означает,
что вы должны перейти вниз по дереву. Это может быть проблемой в сба-
лансированных деревьях.
Например, рассмотрим каталог /usr/lib. Этот каталог содержит мно-
го файлов на первом уровне и много каталогов первого уровня. Если бы
мы не обработали все файлы каталога /usr/lib за одну попытку, мы долж-
ны были бы пойти вниз по подкаталогам каталога /usr/lib. Попытки де-
лать это вручную и запускать pall в каждом подкаталоге заняли бы много
времени и могли бы привести к ошибкам с вашей стороны. Кроме того,
pall допускает указание только одного имени каталога, что приведет к
получению большого количества распечаток и к путанице при их сортиров-
ке.
Что же делать? Радикальным решением является увеличение значения
ulimit. Вы можете сделать это либо с помощью программы на языке Си,
использующей системный вызов ulimit, либо командой shell'а ulimit.
Техника выполнения такой работы представлена в главе 7.
ВОЗМОЖНЫЕ МОДИФИКАЦИИ
Возможно, вы захотите добавить свои собственные штрихи в некото-
рых местах командного файла. Первым местом является то, где указыва-
ются символы поиска файлов программной разработки. Символы, использо-
ванные нами - это наиболее употребимые суффиксы в UNIX. Если вы
используете не Си и ассемблер, а другие языки, то вы можете добавить
соответствующие символы.
Следующим местом, где могут быть сделаны дополнения, являются оп-
ции, которые может понимать pall. Вам могут понадобиться файлы с опре-
деленными именами или определенными типами, например, файлы nroff. Эти
опции могут быть легко добавлены в оператор case, что улучшит команду.
Последним местом возможных изменений является тип файлов, которые
нужно пропускать. Символьная строка для команды egrep покрывает боль-
шинство важных нетекстовых типов файлов. В вашей системе могут быть
какие-то особые типы или же имена могут быть другими. Если вам необхо-
димо дополнить строку, сделайте это. Команда egrep может обработать
довольно много информации. Я не знаю ее ограничений. Возможно, вы об-
наружите их, просматривая исходный текст утилиты egrep. Если получа-
ется слишком длинная строка и не помещается на экране, ничего страшно-
го. Перенос на следующие строки экрана не опасен, пока общее количест-
во символов не превысит 255. Опасно только указывать переадресацию
символьной строки if на нулевое устройство в следующей после команды
egrep строке. Кажется, что все работает правильно, но это не так. Пе-
реадресация должна указываться в той же строке, где стоит команда
egrep.
В данной главе сделано очень много. Наиболее важно то, что полу-
чено множество новых идей, которые можно использовать при эксплуатации
программной среды и просмотре файлов любого типа. В следующей главе мы
углубимся в рутинную работу по ежедневному сопровождению файлов и
используем изученные средства, чтобы они облегчили нашу жизнь.
* ГЛАВА 3. Поддержка файловой системы *
СОДЕРЖАНИЕ
ВВЕДЕНИЕ
3.1. СОПРОВОЖДЕНИЕ ФАЙЛОВ
3.1.1. Операции сопровождения
3.1.2. Средства пересылки файлов
3.1.3. Средства копирования
3.1.4. Средства проверки операции копирования
3.2. ПЕРЕСЫЛКА ФАЙЛОВ
3.2.1. cptdir - копирование дерева каталога
3.2.2. can - удаление файлов в "мусорную корзину"
3.2.3. dosflp - копирование файлов с гибкого диска формата MS-DOS
с использованием символов шаблона в именах файлов
3.3. СРЕДСТВА ПОЛУЧЕНИЯ РЕЗЕРВНЫХ КОПИЙ
3.3.1. autobkp - автоматически наращивамый файл резервной копии
3.3.2. cpiobr - копирование и восстановление файлов в виде потока
данных
3.4. СРЕДСТВА ПРОВЕРКИ ОПЕРАЦИЙ КОПИРОВАНИЯ
3.4.1. dsum - контрольные суммы двух катологов
3.4.2. log - меню доступа к файлам протокола копирования
ВВЕДЕНИЕ
Даже "небольшая" система UNIX с малым числом пользователей порож-
дает сотни файлов в ходе обычной работы. В процессе программирования вы
можете создавать множество файлов для различных версий ваших программ.
Ведение почты и запись текста при помощи редактора vi способствует то-
му, что накапливается еще больше файлов. Такие утилиты, как uucp, lp и
другие добавляют еще больше файлов. Если у вас система UNIX установлена
на микро-ЭВМ, то ваш жесткий диск начинает переполняться. В больших
многопользовательских системах дисковая память редко считается пробле-
мой, но в действительности всегда кажется, будто файлы стремятся расши-
риться до заполнения всей доступной дисковой памяти. Поэтому каждый
