Компания ALT Linux
Опубликован: 14.12.2004 | Доступ: свободный | Студентов: 12067 / 1395 | Оценка: 4.19 / 3.84 | Длительность: 18:18:00
ISBN: 978-5-9556-0019-1
Лекция 6:

Информационное наполнение UNIX

< Лекция 5 || Лекция 6: 1234 || Лекция 7 >
Аннотация: Описание организации информационной подсистемы UNIX. Рассматривается структура руководств (manpages) и подсистемы info. Вводится алгоритм поиска информации.

Руководство

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

Исторически первая, главная и наиболее сбалансированная система документации в UNIX называется " страницы руководства " (manual pages), или, для краткости " руководства " (manuals). (Здесь и далее мы постараемся употреблять слово "руководство" только в качестве перевода manual pages, если же оно понадобится в основном значении, заранее предупредим). Страницы руководства появились уже в первой версии 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.

< Лекция 5 || Лекция 6: 1234 || Лекция 7 >
Andranik Avakian
Andranik Avakian

41. УК РФ и Комментарии (ст. 273)

М. 2000 г. Издательство: ALT Linux, Институт Логики

Уголовный Кодекс РФ и комментарии к нему?

По ссылке открывается сайт документации Linux, раздел Linux Installation and Getting Started

Сергей Петровский
Сергей Петровский

У Вас написано:

ls -dt1 `grep -il отчет *` | head -1

если знания по шелу мне не изменяют, то должно быть:

ls -dt | `grep -il отчет *` | head -1

Марина Дайнеко
Марина Дайнеко
Россия, Moscow, Nope, 2008
Тарас Конюков
Тарас Конюков
Россия