Добавил:

Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Саровский Государственный Физико-технический Институт

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

ГОСЫ / OC_UNIX_Gorkov

.pdf

Скачиваний:

Добавлен:

15.02.2016

Размер:

708.38 Кб

Скачать

☆

1 / 61 2 3 4 5 6 > Следующая >>>

1. История ОС UNIX. Основные понятия ОС UNIX (Пользователь, интерфейс пользователя, привилегированный пользователь, программы, команды, процессы, перенаправление ввода/вывода).

Возникновение и первая редакция ОС UNIX

Принято считать, что исходным толчком к появлению ОС UNIX явилась работа Кена Томпсона по созданию компьютерной игры “Space Travel”. Он делал это в 1969 году на компьютере Honeywell 635, который до этого использовался для разработки проекта MAC. В это же время Кен Томпсон, Деннис Ритчи и другие сотрудники Bell Labs предложили идею усовершенствованной файловой системы, прототип которой был реализован на компьютере General Electric 645. Однако компьютер GE-645, который был рассчитан на работу в режиме разделения времени и не обладал достаточной эффективностью, не годился для переноса Space Travel. Томпсон стал искать замену и обнаружил, что появившийся к этому времени 18разрядный компьютер PDP-7 с 4 килословами оперативной памяти и качественным графическим дисплеем вполне для этого подходит.

После того, как игра была успешно перенесена на PDP-7, Томпсон решил реализовать на PDP-7 разработанную ранее файловую систему. Дополнительным основанием для этого решения было то, что компания Bell Labs испытывала потребность в удобных и дешевых средствах подготовки и ведения документации. В скором времени на PDP-7 работала файловая система, в которой поддерживались: понятие inodes, подсистема управления процессами и памятью, обеспечивающая использование системы двумя пользователями в режиме разделения времени, простой командный интерпретатор и несколько утилит. Все это еще не называлось операционной системой UNIX, но уже содержало родовые черты этой ОС.

Название придумал Брайан Керниган. Он предложил назвать эту двухпользовательскую систему UNICS (Uniplexed Information and Computing System). Название понравилось, поскольку,

помимо прочего, оно напоминало об участии сотрудников Bell Labs в проекте Multics. В скором времени UNICS превратилось в UNIX.

В ноябре 1971 года был опубликован первый выпуск документации по ОС UNIX (”Первая редакция”).

Вторая редакция появилась в 1972 году. Наиболее существенным качеством “Второй редакции” было то, что система была переписана на языке Би (”B”). Язык и интерпретирующая система программирования были разработаны Кеном Томпсоном под влиянием существовавшего языка BCPL.

Появление варианта системы, написанного не на языке ассемблера, было заметным продвижением. Однако сам язык Би во многом не удовлетворял разработчиков. Подобно языку BCPL язык Би был бестиповым, в нем поддерживался только один тип данных, соответствующий машинному слову. Другие типы данных эмулировались библиотекой функций. Деннис Ритчи, который всегда увлекался языками программирования, решил устранить ограничения языка Би, добавив в язык систему типов. Так возник язык Си (”C”). В 1973 году Томпсон и Ритчи переписали систему на языке Си. К этому времени существовало около 25 установок ОС UNIX, и

это			была		“Четвертая			редакция”.
В	июле	1974	года	появилась	“Пятая	редакция”	ОС	UNIX.

В 1975 году компания Bell Labs выпустила “Шестую редакцию” ОС UNIX, известную как V6 или Исследовательский UNIX. Эта версия системы была первой коммерчески доступной вне Bell Labs. К этому времени большая часть системы была написана на языке Си. Небольшие размеры языка и наличие сравнительно легко переносимого компилятора придавали ОС UNIX V6 новое

качество реально переносимой операционной системы. Кроме того, потенциальное наличие на разных аппаратных платформах компилятора языка Си делало возможным разработку мобильного прикладного программного обеспечения.

В настоящее время UNIX – настоящая Вавилонская башня. Различные варианты UNIX

разрабатывают Sun Microsystems (SunOS, Solans), Hewlett-Packard (HP-UX), IBM (AIX), SCO

(SCO UNIX); также существуют клоны UNIX, рассчитанные на работу на базе платформы Intel

(BSD, Linux).

Основные понятия

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

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

Пользователь

С самого начала ОС UNIX замышлялась как интерактивная система. Другими словами, UNIX предназначен для терминальной работы. Чтобы начать работать, человек должен “войти” в систему, введя со свободного терминала свое учетное имя (account name) и, возможно, пароль (password). Человек, зарегистрированный в учетных файлах системы, и, следовательно, имеющий учетное имя, называется зарегистрированным пользователем системы. Регистрацию новых пользователей обычно выполняет администратор системы. Пользователь не может изменить свое учетное имя, но может установить и/или изменить свой пароль. Пароли хранятся в отдельном файле в закодированном виде.

Все пользователи ОС UNIX явно или неявно работают с файлами. Файловая система ОС UNIX имеет древовидную структуру. Промежуточными узлами дерева являются каталоги со ссылками на другие каталоги или файлы, а листья дерева соответствуют файлам или пустым каталогам. Каждому зарегистрированному пользователю соответствует некоторый каталог файловой системы, который называется “домашним” (home) каталогом пользователя. При входе в систему пользователь получает неограниченный доступ к своему домашнему каталогу и всем каталогам и файлам, содержащимся в нем. Потенциально возможен доступ и ко всем другим файлам, однако он может быть ограничен, если пользователь не имеет достаточных привилегий.

Интерфейс пользователя

Традиционный способ взаимодействия пользователя с системой UNIX основывается на использовании командных языков (правда, в настоящее время все большее распространение получают графические интерфейсы). После входа пользователя в систему для него запускается один из командных интерпретаторов (в зависимости от параметров, сохраняемых в файле /etc/passwd). Обычно в системе поддерживается несколько командных интерпретаторов с похожими, но различающимися своими возможностями командными языками. Общее название для любого командного интерпретатора ОС UNIX – shell (оболочка), поскольку любой интерпретатор представляет внешнее окружение ядра системы.

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

Командные языки, используемые в ОС UNIX, достаточно просты, чтобы новые пользователи могли быстро начать работать, и достаточно мощны, чтобы можно было использовать их для написания сложных программ. Последняя возможность опирается на механизм командных файлов (shell scripts), которые могут содержать произвольные последовательности командных строк. При указании имени командного файла вместо очередной команды интерпретатор читает файл строка за строкой и последовательно интерпретирует команды.

Привилегированный пользователь

Ядро ОС UNIX идентифицирует каждого пользователя по его идентификатору (UID – User Identifier), уникальному целому значению, присваиваемому пользователю при регистрации в системе. Кроме того, каждый пользователь относится к некоторой группе пользователей, которая также идентифицируется некоторым целым значением (GID – Group IDentifier). Значения UID и GID для каждого зарегистрированного пользователя сохраняются в учетных файлах системы и приписываются процессу, в котором выполняется командный интерпретатор, запущенный при входе пользователя в систему. Эти значения наследуются каждым новым процессом, запущенным от имени данного пользователя, и используются ядром системы для контроля правомочности доступа к файлам, выполнения программ и т.д.

Понятно, что администратор системы, который, естественно, тоже является зарегистрированным пользователем, должен обладать большими возможностями, чем обычные пользователи. В ОС UNIX эта задача решается путем выделения одного значения UID (нулевого). Пользователь с таким UID называется суперпользователем (superuser) или root. Он имеет неограниченные права на доступ к любому файлу и на выполнение любой программы. Кроме того, такой пользователь имеет возможность полного контроля над системой. Он может остановить ее и даже разрушить.

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

Еще одним отличием суперпользователя от обычного пользователя ОС UNIX является то, что на суперпользователя не распространяются ограничения на используемые ресурсы. Для обычных пользователей устанавливаются такие ограничения как максимальный размер файла, максимальное число сегментов разделяемой памяти, максимально допустимое пространство на диске и т.д. Суперпользователь может изменять эти ограничения для других пользователей, но на него они не действуют.

Программы

ОС UNIX одновременно является операционной средой использования существующих прикладных программ и средой разработки новых приложений. Новые программы могут писаться на разных языках (Фортран, Паскаль, Модула, Ада и др.). Однако стандартным языком программирования в среде ОС UNIX является язык Си (который в последнее время все больше заменяется на C++). Это объясняется тем, что, во-первых, сама система UNIX написана на языке Си, а, во-вторых, язык Си является одним из наиболее качественно стандартизованных языков.

Поэтому программы, написанные на языке Си, при использовании правильного стиля программирования обладают весьма высоким уровнем мобильности, т.е. их можно достаточно просто переносить на другие аппаратные платформы, работающие как под управлением ОС UNIX, так и под управлением ряда других операционных систем (например, DEC Open VMS или

MS Windows NT).

Выполняемая программа может быть запущена в интерактивном режиме как команда shell или выполнена в отдельном процессе, образуемом уже запущенной программой.

Команды

Любой командный язык семейства shell фактически состоит из трех частей: служебных конструкций, позволяющих манипулировать с текстовыми строками и строить сложные команды на основе простых команд; встроенных команд, выполняемых непосредственно интерпретатором командного языка; команд, представляемых отдельными выполняемыми файлами.

Процессы

Процесс в ОС UNIX – это программа, выполняемая в собственном виртуальном адресном пространстве. Когда пользователь входит в систему, автоматически создается процесс, в котором выполняется программа командного интерпретатора. Если командному интерпретатору встречается команда, соответствующая выполняемому файлу, то он создает новый процесс и запускает в нем соответствующую программу, начиная с функции main. Эта запущенная

программа, в свою очередь, может создать процесс и запустить в нем другую программу (она тоже должна содержать функцию main) и т.д.

Перенаправление ввода/вывода Механизм перенаправления ввода/вывода является одним из наиболее элегантных, мощных и

одновременно простых механизмов ОС UNIX. Цель, которая ставилась при разработке этого механизма, состоит в следующем. Поскольку UNIX – это интерактивная система, то обычно программы вводят текстовые строки с терминала и выводят результирующие текстовые строки на экран терминала. Для того чтобы обеспечить более гибкое использование таких программ, желательно уметь обеспечить им ввод из файла или из вывода других программ и направить их вывод в файл или на ввод другим программам.

Реализация механизма основывается на следующих свойствах ОС UNIX. Во-первых, любой ввод/вывод трактуется как ввод из некоторого файла и вывод в некоторый файл. Клавиатура и экран терминала тоже интерпретируются как файлы (первый можно только читать, а во второй можно только писать). Во-вторых, доступ к любому файлу производится через его дескриптор (положительное целое число). Фиксируются три значения дескрипторов файлов. Файл с дескриптором 1 называется файлом стандартного ввода (stdin), файл с дескриптором 2 – файлом стандартного вывода (stdout), и файл с дескриптором 3 – файлом стандартного вывода диагностических сообщений (stderr). В-третьих, программа, запущенная в некотором процессе, “наследует” от породившего процесса все дескрипторы открытых файлов.

В головном процессе интерпретатора командного языка файлом стандартного ввода является клавиатура терминала пользователя, а файлами стандартного вывода и вывода диагностических сообщений – экран терминала. Однако при запуске любой команды можно сообщить интерпретатору (средствами соответствующего командного языка), какой файл или вывод какой программы должен служить файлом стандартного ввода для запускаемой программы и какой файл или ввод какой программы должен служить файлом стандартного вывода или вывода диагностических сообщений для запускаемой программы. Тогда интерпретатор перед выполнением системного вызова exec открывает указанные файлы, подменяя смысл дескрипторов 1, 2 и 3.

Конечно, то же самое может проделать и любая другая программа, запускающая третью программу в специально созданном процессе. Следовательно, все, что требуется для нормального функционирования механизма перенаправления ввода/вывода – это придерживаться при программировании соглашения об использовании дескрипторов stdin, stdout и stderr. Это не очень трудно, поскольку в наиболее распространенных функциях библиотеки ввода/вывода printf, scanf и error вообще не требуется указывать дескриптор файла. Функция printf неявно использует stdout, функция scanf – stdin, а функция error – stderr.

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

Тем не менее, до сих пор можно выделить несколько ветвей ОС UNIX, различающихся не только реализацией, но временами интерфейсами и семантикой (хотя, по мере развития процесса стандартизации, эти различия становятся все менее значительными).

2. Информационное наполнение UNIX. Описание организации информационной подсистемы UNIX. Структура руководств (manpages) и подсистемы info. Алгоритм поиска информации.

Описание организации информационной подсистемы UNIX. Рассматривается структура руководств (manpages) и подсистемы info. Вводится алгоритм поиска информации.

Руководство

Как уже неоднократно отмечалось, аккуратная документация - непременная составная часть проективной системы. Чтобы по всякому поводу не приниматься изучать систему целиком, надо предусмотреть средство ограничения контекста, позволяющее выбирать документацию по теме. Выходит, что документацией по какой-нибудь утилите не могут служить, скажем, технические замечания, Changelog (он же Whatsnew) и даже README, включаемые в исходные тексты данной утилиты. Это, условно говоря, документация для программистов (точнее - для тех, кто будет улучшать или исправлять саму утилиту). Нас же интересует документация для пользователей (т. е. для тех, кому утилита понадобится в работе). К тому же описание утилиты и способов ее применения должно быть дополнено некоторой задающей контекст информацией: для чего утилита, чем она пользуется, что еще стоит почитать. Если речь идет о внушительных размеров пользовательском прикладном пакете, которым не пользуются другие части системы, стоит рассматривать сам этот пакет как систему, внутри которой опять-таки требуется ограничивать контекст, дабы не изучать ее целиком (так устроена, например, документация по

Tcl/Tk).

Исторически первая, главная и наиболее сбалансированная система документации в UNIX называется "страницы руководства" (manual pages), или, для краткости "руководства" (manuals). (Здесь и далее мы постараемся употреблять слово "руководство" только в качестве перевода manual page, если же оно понадобится в основном значении, заранее предупредим). Страницы руководства появились уже в первой версии UNIX: не все писали утилиту, но все хотят ею пользоваться (а вначале появлялись самые нужные), и тут без документации - никуда. А поскольку некая система документирования в то время уже существовала (см. 5), ее и взяли за основу. На примере того, как организованы страницы руководства, хорошо видно, как формировались принципы построения системы, из чего они произрастали и как они работают сейчас, со всеми их достоинствами и недостатками.

Средством просмотра страниц руководства служит утилита man. Самый простой способ ею воспользоваться - написать что-нибудь в командной строке man. Например, команда man man выдаст руководство по самой этой утилите, которое можно просмотреть постранично, перелистывая страницы клавишей "пробел". Если вы пользуетесь каким-нибудь инструментом UNIX, но еще не читали его руководства, прочитайте непременно! Хотя бы для того, чтобы иметь представление обо всех его возможностях. Руководства есть не только у каждой утилиты системы, но и у многих других объектов. Все страницы руководства отнесены к восьми разделам:

1.пользовательские утилиты и прочие инструменты;

2.системные вызовы;

3.библиотечные вызовы (функции);

4.внешние устройства (и их представление в системе);

5.форматы и таблицы (типы файлов, протоколы и пр.);

6.игры и всевозможные "ненужные" утилиты (например, fortune);

7.прочее, т. е. то, что не подходит под другие разделы;

8.команды и инструменты системного администратора.

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

Поля руководства

Все грамотно написанные страницы руководства состоят из нескольких полей, названия которых во всех руководствах одинаковы, но не обязательно все поля должны присутствовать в одном руководстве. Названия полей располагаются в начале строки (остальной текст идет с отступом) и выделяются повышенной яркостью. В каждом поле объект, которому посвящено руководство,

рассматривается с определенной точки зрения (Среди руководств ALT Linux есть совершенно очаровательное - по объекту baby. Помимо прочего, в нем аккуратно расписаны все основные поля, так что настоятельно советуем почитать его на предмет изучения структурной организации страницы руководства. К тому же там содержится немало ценных сведений о самом объекте).

Краткое описание

Семантическое

Первое поле - NAME - содержит только имя объекта и его очень краткое, на одну строку, описание. NAME - суть всего руководства, поэтому очень важно, чтобы описание, при всей краткости, давало полную и четкую картину описываемого.

Синтаксическое

Поле SYNOPSIS описывает общий вид использования объекта. Например, в случае утилиты оно представляет собой командную строку со всеми возможными параметрами. В таком виде утилита, скорее всего, никогда не будет вызвана, однако общий вид описывает, как передавать ей параметры и какие именно. В SYNOPSIS должны быть представлены все варианты использования; для этого разработан даже специальный язык сокращений. Например, квадратные скобки обозначают необязательность параметра, фигурные - выбор одного параметра из списка (тогда они разделяются символами "|"), многоточие - повторение и т. д. Тем не менее SYNOPSIS - тоже очень краткое поле, позволяющее "единым взглядом" охватить возможности и специфику объекта.

Описание

Поле DESCRIPTION содержит развернутое описание объекта. Сюда попадает любая разъяснительная информация: принципы работы данной утилиты или функции, назначение и общая структура данного системного файла, описание внешних устройств, соответствующих данному драйверу и т. п. Поле может быть довольно большим: информации в нем должно быть достаточно для понимания устройства и работы объекта. Если утилита сама по себе сложна и описание принципов ее работы в DESCRIPTION довольно пространно, перечень возможных параметров командной строки (иными словами, ключей) с подробным изложением того, как и зачем их применять, выносят в поле OPTIONS. Если работа инструмента зависит от каких-либо переменных окружения (см. лекцию 17), их список помещается в поле ENVIRONMENT.

Результат

Функция или системный вызов, как правило, возвращают какое-нибудь значение. По окончании работы утилиты вырабатывается так называемый код возврата (или код ошибки, который не равен нулю в случае неудачного завершения работы). Наконец, функция или системный вызов могут завершиться с разными видами ошибок. Для описания результатов работы в руководствах имеются поля RETURN VALUES, DIAGNOSTICS и ERRORS соответственно.

Использование

Иногда использование объекта невозможно или некоторый, на первый взгляд очевидный путь его применения приводит к неочевидным последствиям. Тогда стоит поместить примеры такого рода ситуаций в поле CAVEATS. Небольшие примеры успешного использования объекта с описанием решаемой в них задачи приводятся в поле EXAMPLES, а типичные ошибки при работе с объектом, равно как и недочеты в его реализации, - в поле BUGS.

Ссылки на другие объекты

Если утилита работает с какими-нибудь файлами, использует или изменяет их, эти файлы перечисляются в поле FILES, даже если на них нет руководства. Поработав с некоторым инструментом системы, пользователь может просмотреть все файлы из поля FILES руководства, и узнать, откуда этот инструмент взял дополнительные данные и что изменил. Одно из самых важных - поле SEE ALSO. В него включаются ссылки на те источники информации, которые автор руководства считает относящимися к теме: на книги, включенные в систему учебники и статьи и - главное - на другие страницы руководства. Кроме того, в тексте всего руководства непременно встретятся ссылки на другие объекты, по которым тоже есть руководства. В этом случае, как и в поле SEE ALSO, после имени объекта в скобках указывается номер раздела, в котором стоит искать руководство.

Прочее

На самом деле структура руководства совсем не такая жесткая, как это может показаться из нашего описания. Зачастую даже хотелось бы, чтобы она была пожестче (например, чтобы ключи утилит всегда выносились в отдельное поле OPTIONS или чтобы поле EXAMPLES присутствовало всегда). Вполне допустимо вводить новые поля, особенно когда руководство весьма велико и его надо структурировать (например, COMMANDS - для команд с клавиатуры, COMPATIBILITY - для описания совместимости с предыдущими версиями и т. п.); ненужные поля можно опускать.

Родословная

Нередко в руководство включается поле HISTORY, где кратко описывается, когда в какой именно системе впервые появился объект и как он впоследствии развивался. Сведения об авторах, адрес, куда присылать жалобы и предложения (электронный и обычный) и прочую контактную информацию помещают в поле AUTHORS.

Особенности руководств

Бывают объекты с одинаковыми именами, но принадлежащие разным разделам, например утилита passwd, позволяющая пользователю менять пароль, и файл passwd, в котором хранится учетная запись пользователя (по иронии судьбы в современных версиях UNIX именно пароля там

инет). Для того чтобы посмотреть руководство по passwd из пятого раздела, надо использовать команду man 5 passwd, а если вам неизвестно, к какому разделу относится объект, - man -a passwd (тогда вы увидите руководства по всем объектам с именем passwd). При ссылке на страницу руководства принято после имени объекта указывать в круглых скобках номер раздела passwd(1)

иpasswd(5).

В каждом разделе существует специальный объект intro, руководство по которому описывает назначение раздела и определяет основные термины. Кроме того, в поле SEE ALSO этих руководств помещаются ссылки на страницы руководства по крупным темам (например, security(7)).

Тем не менее сеть страниц руководства - это совсем не учебник по UNIX. Тому есть три причины. Во-первых, учебник - это свод только основных знаний о предмете изучения (отрасли науки, сфере деятельности человека, некотором инструментарии и т. п.) и цель его - донести эти знания в наиболее доступном изложении. Поэтому основную часть учебника занимают вопросы обучающего плана: упражнения, разъяснения, попытки увязать факты в единую схему и т. д. Цель же руководства - сообщить все, что известно об объекте (например, поточном текстовом редакторе sed), и указать на то, что существует некий предмет рассмотрения, с которым этот объект связан (автоматическая обработка текстов). Причем указание это делается не напрямую, а

путем ссылок на иные объекты, тоже относящиеся к делу. Руководство - это справочник; его читают, когда имеют представление о том, что делать, но не знают в точности - как.

Смысловая структура системы руководств

Первое, что бросается в глаза, - это ее совершенно естественное происхождение. Трудно поверить, что создатели этой структуры потратили много времени на ее измышление, штудируя труды по эргономике, проектированию систем, гипертекстам и т. д. Кажется, если бы нам самим захотелось разработать систему информационной поддержки, мы бы сделали ее почти такой же. Тем не менее устройство подсистемы руководств носит следы и основ эргономики (правило "7±2", [32]), и принципов построения компьютерных систем, а также очевидной гипертекстовой структуры: в страницах руководства есть несколько видов гипертекстовых ссылок. Никаких механизмов перехода по ссылкам в manpages не предусмотрено: предполагается, что, во-первых, сначала лучше дочитать открытое руководство, а во-вторых, если потребуется, всегда можно запустить команду man на соседнем терминальном устройстве (виртуальной консоли или X- терминале). К тому же технически переход по некоторым видам ссылок реализовать не так просто, как это предлагают, скажем, средства просмотра HTML, где используются только контекстные гиперссылки.

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

Объектные ссылки указывают на реальные объекты системы, например файлы в поле FILES. Этот вид ссылок определяет область действия инструмента, т. е. определяет не смысловую, а актуальную, действующую связь. Объектные ссылки помогают определить список объектов, которые надо скопировать или проверить перед применением соответствующего инструмента, или изучить после воздействия на систему. Это - род концевых ссылок, потому что из информационного пространства рассмотрение переходит в объектное.

Внешние ссылки отсылают к документации, оформленной не в формате manpage. Это может быть учебник, документация в формате info (о ней мы поговорим позже), статья по теме и т. п. Главная особенность внешних ссылок - в том, что за ними стоит по-другому и для другого организованное информационное пространство. Так что нужны они тем читателям, кто ищет в руководстве нечто, ему не свойственное: например, ответ на типовой вопрос. Из типовых вопросов и ответов обычно составляется документ под названием FAQ (frequently asked questions, или часто задаваемые вопросы, ЧаВо), а специфике руководства это не соответствует. Поэтому где-нибудь в поле SEE ALSO должна находиться внешняя ссылка на подобный документ.

Летописными ссылками мы будем называть всякое упоминание не относящихся к предмету рассмотрения объектов: историю создания утилиты, авторов, www-страницу и пр., что встречается чаще всего в полях AUTHORS, HISTORY, AVAILABILITY и т. п. Эти ссылки либо вообще приводятся для удовлетворения любопытства пользователей, либо просто косвенно дополняют описание.

Утилита man

Утилита man(1) - составная, ее вызов - это последовательное выполнение трех операций: поиск страницы руководства, форматирование найденной страницы и просмотр отформатированного текста.

Сами страницы помощи - это файлы, имена которых включают имена объектов (об этом будет подробнее рассказано в лекции 13). Файлы расположены в некотором базовом каталоге

(например, в /usr/share/man или в /usr/X11R6/share/man) в подкаталогах man1, man2 и т. д. по количеству разделов. Таким образом, первая стадия работы утилиты man сводится к поиску первой страницы с именем объекта во всех секциях базовых каталогов. Кстати, именно поэтому секция, посвященная администрированию, сделана восьмой: если пользователь вызовет man без указания раздела, то при совпадении имен объектов он получит руководство по утилите, а системному администратору ничего не стоит написать в командной строке man 8.

Третья стадия работы man - вызов утилиты постраничного просмотра текста more(1). Подобие more, лишенное всех функций, кроме главной, можно найти даже в DOS. Во многих современных системах вместо more используется более мощная утилита less(1). Говорят: "Less is more than more". Утилита позволяет просматривать простой текст и текст, выходящий из-под nroff, при этом используются возможности терминала: "двойной удар" превращается в текст повышенной яркости, а подчеркивание - в подчеркнутый. (В системе Solaris man почему-то вызывает more с ключом, запрещающим обрабатывать подчеркнутый текст, отчего внешний вид руководства ухудшается.) Исходные тексты утилиты more в Solaris недоступны, и приходится подменять ее командным сценарием, в котором параметры командной строки передаются настоящей утилите more уже поправленными. Если вы хотите вывести руководство на печать, причем не на АЦПУ, а на современный PostScript-принтер, лучше не обрабатывать выдачу man, а воспользоваться предназначенной для этого утилитой troff(1). Получившаяся командная строка может быть, например, такой:

zcat /usr/share/man/man1/man.1.gz |

troff -man -Tps | grops | lpr

Для каждой из этих утилит есть руководство, а о том, что такое "|" ("конвейер"), рассказано в лекции 11.

Утилиты whatis и apropos

Самая краткая часть страницы руководства - однострочное поле NAME - тоже играет очень важную роль в системе информационной поддержки. Дело в том, что при установке руководства в систему содержимое этого поля добавляется в файл whatis, лежащий в базовом каталоге. Текстовый файл whatis - оглавление всей системы руководств, находящейся в соответствующем каталоге. Если поискать некоторое слово в этом файле, мы увидим только те заголовки руководств, в которых оно встречается. Поиском ключевых слов в whatis занимаются утилита whatis(1) и apropos(1), которая ищет не целое слово, а просто подстроку в строке.

Работа с руководствами

Допустим, мы хотим слить два файла, left и right, в один, состоящий из двух колонок (содержимое одного файла - слева, другого - справа). Спрашиваем, в описании каких утилит есть слово column:

$ apropos column

...

Команда apropos выдает несколько сотен строк относящихся в основном, к графическим функциям (секция 3). Нас же интересует утилита (секция 1). Используем grep(1), чтобы выбрать только строки, содержащие (1) (поле NAME начинается с контекстной ссылки на само руководство).

$ apropos column | grep "(1)"

colrm(1) - remove columns from a file

column(1) - columnate lists

Другое дело! Наверное, нам нужна утилита column? Читаем руководство.

$ man column

...

Не тут-то было... Смотрим поле SEE ALSO

$ man column | colcrt | sed -n '/SEE ALSO/,/^$/p'