Re: [RFR] po4a://manpages-l10n/po/ru/man7/man-pages.7.po
Fat-Zer <[email protected]> Mon, 20 Jan 2025 07:58:44 +0300
| Newsgroups | gmane.linux.debian.internationalization.russian |
|---|---|
| Message-ID | <CANi=-v+kTYxo+4pkNDux6yT4TW3VkbT3-SbO_qR4XRCgEWCMSQ@mail.gmail.com> |
Спасибо за проверку. Перевод обновлён. Новые изменения: https://salsa.debian.org/Fat-Zer/manpages-l10n/-/commit/22fd3508262769fd082c45365627c879b93928ed Полный список изменений: https://salsa.debian.org/Fat-Zer/manpages-l10n/-/commit/8fdda8cb696078fd30e95401724e89300258746d Текущий PO: https://salsa.debian.org/Fat-Zer/manpages-l10n/-/blob/8fdda8cb696078fd30e95401724e89300258746d/po/ru/man7/man-pages.7.po Текущая переведённая версия страницы в html приложена к письму; --------------- вс, 19 янв. 2025 г. в 23:09, Andrey Dogadkin <[email protected]>: > > On Thu, 2025-01-16 at 02:15 +0300, Fat-Zer wrote: > > https://salsa.debian.org/manpages-l10n-team/manpages-l10n/-/merge_requests/26/diffs?commit_id=aedd89b02536a42fd4c8b18096e083532608d7db > > > > "там где страница рекомендует использования определённых терминов или > > " > > "рекомендует использованиЕ" > исправлено [1] > > > "формулировок, по возможности, приводятся как их англоязычные так и " > > "русскоязычные версии; однако данная страница не является > > авторитетным " > > "источником о том, как должны выглядеть переведённые страниц > > руководства." > > Пропущена запятая перед "так". См. [1]. > > На мой взгляд фраза "не является авторитетным источником о том ..." > звучит неестественно. Возможно, лучше написать "не является > авторитетным источником информации о том ..."? > > Также "переведённые страницЫ". > "не является авторитетным источником информации о том ..." — принято исправлено [1] > > > msgstr "Аргументы этой команды следующее:" > > "Аргументы ... следующИе" > исправлено [1] > > > "Обычно, этот аргумент должен оставаться пустым, т.к. значение по > > умолчанию и " > > Мне кажется, что запятая после "обычно" не нужна. > убрал[1] > > > "которые B<выделенны полужирным>. При создании новой справочной > > страницы " > > "выделеНы полужирным" > исправлено [1] > > > msgstr "[Обычно, только в Разделах 2 и 3]" > > msgstr "[Обычно, только в Разделе 4]" > > msgstr "[Обычно, только в Разделах 1 и 8]" > > msgstr "[Обычно, только в Разделах 2 и 3]" > > Здесь тоже смущает постановка запятой. Возможно, другие участники меня > поправят, но из того, что я смог найти в интернете, "обычно" никогда не > выступает в роли вводного слова и не обособляется. > ок, пока убрал везде [1] > > > "приводятся все необходимые объявления данных или директивы > > B<#include> после " > > "которых следует объявление функции." > > Пропущена запятая перед "после". > > Возможно, по аналогии с вашей правкой стоит также заменить > "показываются" на "приводятся" выше в этом же сообщении. > исправлено и весь абзац перефразирован [1] Новый текст: «Для команд здесь приводятся синтаксис и аргументы (включая параметры); полужирное начертание используется для текста, который должен использоваться дословно, а курсивом обозначаются изменяемые аргументы. Необязательные аргументы приводятся в квадратных скобках ([]), вертикальной чертой (|) разделяются альтернативные варианты, многоточие (\&...) показывает возможность повторения. Для функций приводятся все необходимые объявления данных или директивы B<#include>, после которых следует объявление функции.» > > > "Если для получения из заголовочного файла объявления функции (или " > > "переменной) требуется определить макрос тестирования свойств, то это > > также " > > "указывается в разделе ОБЗОР, как это описано в > > B<feature_test_macros>(7)." > > Мне кажется, что первоначальный вариант перевода здесь ближе к > англоязычному оригиналу, а предложения в нём лучше согласованы. Может > оставить его, исправив разве что "в ОБЗОРЕ" на "в разделе ОБЗОР"? > В первой части порядок слов вернул к старому — здесь не то чтобы оно сильно влияет. В остальном, мне не нравится конструкция «согласно описанию из». И «также» я также специально оставил/добавил ради логической связи с остальным текстом > > > msgid "This section normally appears only in Section 4 pages." > > msgstr "Этот раздел, как правило, присутствует только в Разделе 4." > > "Раздел в разделе" звучит достаточно запутанно. Может, написать > "присутствует только на страницах Раздела 4" как в оригинале? > да, хорошо; исправлено[1] > > > "Этот раздел как правило содержится только в справочных страницах > > разделов 1 " > > "и 8." > > "как правило" следует выделить запятыми, см. [2]. > исправлено[1] > > > "Если одна и та же ошибка возникает по нескольким различным причинам, > > " > > "предпочтительней для каждой из них создавать отдельные записи в > > списке (с " > > "повторением имени ошибки). Такое разделение делает условия > > возникновения " > > Насколько я понимаю, одной причине соответствует одна запись, поэтому > "создавать отдельную запись в списке". > тоже думал над этим; множественное число немного ближе к оригиналу и, вроде бы, тоже грамматически верное, хотя оно и как-то режет слух, но всё же решил оставить во множественном... но раз я не один такой, то пусть будет в единственном. исправлено[1] > > > "A summary of systems where the API performs differently, or where > > there's a " > > "similar API." > > msgstr "" > > "Краткий обзор систем, на которых данный API функционирует по-другому > > или на " > > "которых есть похожие API." > > Мне кажется, правильнее будет: > "Краткий обзор систем, в которых данный API функционирует по-другому > или имеется похожий API." > да, исправлено[1] > > > msgid "" > > "This section should note the current standards to which the API > > conforms to." > > msgstr "" > > "В данном разделе должны содержаться заметки, какому текущему > > стандарту " > > "соответствует данный API." > > Может, лучше сказать "... заметки о том, ..."? > не вижу особой разницы, но пусть будет > > > "Если API не соответствует ни какому стандарту, но существует во > > множестве " > > "систем,об этом также стоит упомянуть. Если вызов есть только в Linux > > или GNU-" > > "специфичный, то это тоже стоит отметить. Если он доступе только в > > BSD-" > > "системах, отметьте и это." > > "никакому" должно быть слитно. Между запятой и предлогом "об" пропущен > пробел. > > Наверное, лучше написать "Если вызов есть только в Linux или GNU ..." > или "Если вызов является специфичным для Linux или GNU ...". > > Также "если он доступеН ...". > исправлено, исправлено [1] хорошо, «Если вызов является специфичным для Linux или GNU ..."» исправлено > > > "ИСТОРИЯ в справочной странице. К сожалению, для многих справочных > > страницах " > > "эта информация отсутствует (когда они были написаны, этого правила > > ещё не " > > "... НА многих справочных страницах ..." > исправлено на «…ВО многих справочных страницах…» [1] > > > "Linux 2.4 или позже (т.е., были изменены со времён Linux 2.2), а для > > " > > "библиотечных функций, если изменения были добавлены начиная с glibc > > версии " > > "2.1 (т.е., были изменены со времён glibc 2.0)." > > Лишние запятые после "т.е.", см. [3]. То же самое в аналогичном > сообщении ближе к концу файла. > исправлено везде [1] > > > "Старые версии стандартов должны упоминаться здесь, а не в разделе > > СТАНДАРТЫ, " > > "например, SUS, SUSv2, и XPG, или стандарты реализаций SVr4 и > > 4.xBSD." > > Мне кажется, запятые после "например" и перед "и" не нужны. > после «например» — нужна, перед «и» — нет; перед «или», по идее, тоже не нужда; изменено [1] + я ещё перестроил фразу: «Старые версии стандартов (например, SUS, SUSv2 и XPG или стандарты реализаций SVr4 и 4.xBSD) должны упоминаться здесь, а не в разделе СТАНДАРТЫ.» > > > "(I<C library/kernel differences>), чтобы отметить различия (если > > имеются) " > > "между функциями-обёртками в библиотеке Си и интерфейсом системных > > вызовов, " > > "предоставляемый самим ядром." > > "интерфейсом ... предоставляемыМ" > исправлено [1] > > > "Предупреждения о распространённых практиках неправильного > > использования API " > > "пользователями, которые не являются себя ошибками реализации или в > > дефектами " > > "проектирования." > > "себя" и "в" здесь лишние. > исправлено [1] > > > "visual result of the output, it may be useful to employ the I<.ad l> > > (don't " > > "right justify) and I<.nh> (don't hyphenate) directives. > > Hyphenation of " > > "воспользоваться командами I<.ad l> (выровнять по левому краю без " > > "выравнивания по ширине) и I<.nh> (отключить перенос). Предотвратить > > перенос " > > Вариант перевода "не выравнивать по правому краю", который был > первоначально, ближе к оригиналу. > нет, «выравнивать по правому краю» — это «right align». «justify» — это «выровнять по ширине». Я не уверен что именно подразумевается под «right justify», но предполагаю , что это «выровнять абзац по ширине, а в последней строке оставить отступ справа», как это обычно делает man, но сама команда означает «выровнять по левому краю». немного упростил до: «выровнять по левому краю, а не по ширине» [1] > > > "Следующие подразделы описывают некоторые детали соглашений > > касающихся " > > "предпочтительных вариантов форматирования и формулировок в различных > > " > > "разделах справочных страниц проекта I<man-pages>." > > Пропущена запятая перед "касающихся". > исправлено [1] > > > "Оборачивайте прототипы функций в I<.nf>/I<.fi>, чтобы предотвратить > > их " > > "расползание по ширине страницы." > > "Выравнивание", на мой взгляд, будет стилистически более уместным, чем > "расползание". > Здесь я ошибся, должно быть «чтобы предотвратить переносы строк». [3] исправлено [1] > > > "Предпочтительная формулировка для описания того, какое значение " > > "устанавливается в I<errno>: «I<errno> устанавливается в > > соответствующее " > > "значение» («I<errno> is set to indicate the error») или аналогичное. > > Эта " > > "формулировка ... аналогичнАЯ" > исправлено [1] > > > "Wrap the table in this section in a I<.ad\\ l>/I<.ad> pair to > > disable text " > > "filling and a I<.nh>/I<.hy> pair to disable hyphenation." > > "Оборачивайте таблицы в этом разделе в I<.ad\\ l>/I<.ad>, чтобы > > предотвратить " > > "их расползание, а также в I<.nh>/I<.hy>, чтобы предотвратить > > переносы слов." > > В оригинале речь про "text filling", возможно, лучше заменить "их > расползание" на "выравнивание текста по ширине". > просто «выравнивание по ширине»; исправлено [1] > > > "разбиты на несколько строк (при этом учитывайте, что страницы иногда > > могут " > > "отображаться на экранах шириной менее 80-и столбцов)." > > Лучше "80-ти", ещё лучше - просто "80", см. [4]. > моя ошибка, количественные числительные не наращиваются, исправлено [1] > > > "I<man-pages>. Если что-то в данном разделе описано недостаточно > > подробно, то " > > "следует придерживаться рекомендаций Чикагское руководство по стилю > > (Chicago " > > "рекомендаций ЧикагскоГО руководствА по стилю" > исправлено [1] > > > "Для справочных страниц, описывающих команды (как правило в Разделах > > 1 и 8), " > > Кажется, пропущена запятая после "как правило" (не уверен, является ли > употребление в скобках особым случаем). > исправлено [1] > > > msgstr "Имя команды и её параметры, всегда должны быть выделены > > полужирным." > > Запятая лишняя. > исправлено [1] > > > "В справочных страницах, которые описывают функции (обычно, в > > Разделах 2 и " > > "3), параметры всегда оформляются, используя курсив; I<даже в разделе > > ОБЗОР>, " > > Лишняя запятая после "обычно", см. выше. > исправлено [1] > > > "Любая ссылка на предмет текущей справочной страницы должна быть > > оформлена в " > > "виде имени этой страницы в полужирном начертании, за которым следует > > пару " > > "круглых скобок, в обычном начертании. Например, на странице > > B<fcntl>(2), " > > "ссылки на её тему должны выглядеть как: B<fcntl>(). Рекомендуемый > > способ " > > "записи этого в исходном файле:" > > "за которым следует парА круглых скобок" > > Лишние запятые перед "в обычном начертании" и после "на странице > B<fcntl>(2)". > исправлено [1] ИМХО обе эти запятые факультативны, но их я тоже убрал. > > > "(1), (2). Они представляют собой некий набор пунктов идущих в > > определённом " > > "порядке." > > Пропущена запятая перед "идущих". > исправлено [1] > > > "Если список описывает поля какого-либо файла, дабы это > > согласовывалось с " > > "такими утилитами как B<cut>(1)." > > Пропущена запятая перед "как", см [5]. > исправлено [1] > > > "(включение номера раздела в перекрёстных ссылках позволяет таким " > > "инструментам как B<man2html>(1) создавать страницы с правильными " > > "гиперссылками)" > > Аналогично. > исправлено [1] > > > msgstr "Употребление прописн букв" > > "прописнЫХ" > уже исправлено [2] > > > "При включении определений структур, журналов сеансов оболочек и т.п. > > в " > > "основной текст, нужно использовать отступ в 4 пробела (т.е., > > заключить блок " > > В исходном варианте перевода "т. п." и "т. е." скорее всего написаны с > пробелом осознанно, так как такое написание является более правильным > (хотя для меня - непривычным). См. [6]. > > Лишняя запятая после "т.е.". > > То же самое в аналогичном сообщении ближе к концу файла. > уже исправлено [2], всё исправлено [1] > > > "I<Указатель null> или I<нулевой указатель> (I<null pointer>) — это " > > "указатель, который ни на что не указывает и, как правило > > обозначается " > > "константой I<NULL>. С другой стороны, I<NUL> представляет собой > > I<байт null> " > > Пропущена запятая после "как правило". То же самое в аналогичном > сообщении ближе к концу файла. > всё исправлено [1] > > > "Единственным местом, где подобные сокращения могут быть уместны — > > это " > > "I<короткие> отступления в скобках (т. е. как вот это). Примечание " > > "переводчика: в русскоязычных справочных страницах применяются только > > " > > "сокращения «и т. д.», «т. е.» и «прим. пер.»; после точки всегда > > ставится " > > "пробел." > > "ЕдинственнОЕ место, где ..." > > Мне также кажется, что перед тире здесь нужна запятая, чтобы закрыть > придаточное "где ...". > > Не совсем понятно, откуда взята информация в примечании про список > допустимых сокращений в русскоязычных переводах. > исправлено [1] исправлено я имел в виду, «что напр.» не применяется. Убрал здесь и добавил [1] к следующему абзацу следующий текст: Примечание переводчика: в русскоязычных справочных страницах после каждой точки в «т. е.», «и т. д.» и т. п. ставится пробел; кроме того сокращение «напр.» для «например» не используется . > > > "Добавлять в текст длинно тире \\[em] глиф, которым выделено данное " > > "уточнение, \\[em] в *roff следует с помощью макроса «\\[rs][em]» (в > > ASCII-" > > "терминалах, тире, обычно, отображается в виде двух чёрточек, но в > > других " > > "типографских контекстах оно может выглядеть как простое длинное > > тире). Тире " > > "длинноЕ тире" > > В предложении "в ASCII-терминалах тире обычно отображается в виде двух > чёрточек, ..." запятые не нужны. То же самое в аналогичном сообщении > ближе к концу файла. > исправлено [1] оба исправлены > > > "Finally, note that \"re-create\" and \"recreate\" are two different > > verbs, " > > "and the former is probably what you want." > > "И напоследок заметим, что «re-create» (создать снова) и «recreate» " > > "(пересоздать) — это два различных глагола и вы, вероятно, хотите " > > "использовать последний." > > Мне кажется, здесь отсылка к re-create (в значении создать снова, > пересоздать) и recreate (в значении поправляться, развлекаться). И в > оригинале предлагают использовать первый (former), а не последний. > да, точно. я это упустил =) исправлено[1] > > > "Создания глифов, которые при копировании из готовых страниц будут > > давать " > > "настоящие знаки минус при вставке в терминал." > > "СозданиЕ" > исправлено[1] > > > "Чтобы получить одинарные кавычки, которые хорошо отображаются и в > > ASCII и в " > > "UTF-8, используйте «\\[rs][aq]» («apostrophe quote», «апострофная > > кавычка»); " > > Не хватает запятой после "ASCII". > исправлено[1] > > > "Когда требуется правильно отображаемый символ циркумфлекс (\\[ha]), > > который " > > "будет хорошо смотреться как в терминале, так и в PDF, используйте > > «\\e[ha]». " > > "Это особенно важно в примерах кода, чтобы получить красивые символы > > " > > "циркумфлекса при выводе в PDF." > > Здесь речь идёт про карет (caret, ^), а не циркумфлекс. > У меня была какая-то причина, почему я решил использовать «циркумфлекс», но уже не помню, почему... исправлено[1] > > > "Для удобства восприятия, все программы должны завершаться с > > использованием " > > "одного из:" > > Запятая после "восприятия" не нужна. > > Субъективно, первоначальное "с использованием одного из вариантов:" > звучало лучше, так как далее следует список непереводимых конструкций > языка программирования. Возможно, ещё лучше будет "с использованием > одного из следующих вариантов:". > исправлено[1] да Плюс добавил пару потерянных слов: Ради единообразия и удобства восприятия все программы в примерах должны завершаться с использованием одного из следующих вариантов: > > > "Если вы включаете лог вывода в терминал, демонстрирующий > > использование " > > "программы или системной функции:" > > > msgstr "Поместите лог вывода перед листингом с кодом программы." > > > msgstr "Выделите лог вывода отступом в четыре пробела." > > Лог - журнал. > исправлено везде[1] > > > "Элементы этих списков предваряются символом маркера (B<\\e[bu]>). > > Все " > > "списки, которые не вписываются в другие типы, обычно покрывается > > этим." > > "покрываЮтся" > исправлено [1] [1]: https://salsa.debian.org/Fat-Zer/manpages-l10n/-/commit/22fd3508262769fd082c45365627c879b93928ed [2]: https://salsa.debian.org/Fat-Zer/manpages-l10n/-/commit/5f613685f1a6be92af74a9a124077809c23b3056 [3]: https://www.gnu.org/software/groff/manual/groff.html#index-_002enf
man-pages.7.html
(text/html, 79 KB)
Content-type: text/html
<HTML><HEAD><TITLE>Manpage of man\-pages</TITLE>
</HEAD><BODY>
<H1>man\-pages</H1>
Section: Environments, Tables, and Troff Macros (7)<BR>Updated: 15 июня 2024 г.<BR><A HREF="#index">Index</A>
<A HREF="http://localhost/cgi-bin/man/man2html">Return to Main Contents</A><HR>
<A NAME="lbAB"> </A>
<H2>НАИМЕНОВАНИЕ</H2>
man-pages - правила написания справочных страниц Linux
<A NAME="lbAC"> </A>
<H2>ОБЗОР</H2>
<B>man</B> [<I>раздел</I>] <I>имя</I>
<A NAME="lbAD"> </A>
<H2>ОПИСАНИЕ</H2>
На этой странице описаны правила, которые необходимо применять при написании
справочных страниц для проекта <I>man-pages</I> Linux, который, в свою очередь,
документирует программный интерфейс пространства пользователя,
предоставляемый ядром Linux и библиотекой GNU C. Таким образом, проект
отвечает за большинство страниц из Раздела 2, за многие страницы из Разделов
3, 4, и 7, и за несколько страниц из Разделов 1, 5 и 8 справочной системы
Linux. Данные правила также могут быть полезны при написании справочных
страниц для других проектов. Примечание переводчика: эта страница прежде
всего описывает правила для написания исходных, англоязычных версий
справочных страниц, так что детали их русских переводов могут отличаться;
там где страница рекомендует использование определённых терминов или
формулировок, по возможности, приводятся как их англоязычные, так и
русскоязычные версии; однако данная страница не является авторитетным
источником информации о том, как должны выглядеть переведённые страницы
руководства.
<A NAME="lbAE"> </A>
<H3>Разделы справочных страниц</H3>
В качестве традиционных определены следующие Разделы руководства:
<DL COMPACT>
<DT><B>1 Команды пользователя (Программы)</B><DD>
Команды, которые пользователь может запускать из оболочки.
<DT><B>2 Системные вызовы</B><DD>
Функции, являющиеся обёрткой операций, выполняемых ядром.
<DT><B>3 Библиотечные вызовы</B><DD>
Все библиотечные функции (в основном функции <I>libc</I>), за исключением
представленных в Разделе 2.
<DT><B>4 Специальные файлы (устройства)</B><DD>
Файлы из <I>/dev</I>, дающие доступ к устройствам через ядро.
<DT><B>5 Форматы файлов и конфигурационные файлы</B><DD>
Описывает различные форматы файлов, предназначенные для чтения человеком, и
конфигурационные файлы.
<DT><B>6 Игры</B><DD>
Игры и небольшие забавные программы, доступные в системе.
<DT><B>7 Обзоры, соглашения и разное</B><DD>
Описания или обзоры, касающиеся различных тем, соглашений и протоколов:
наборов символов, стандартной структуры файловой системы и других
разнообразных вещей.
<DT><B>8 Команды для системного администрирования</B><DD>
Команды подобные <B><A HREF="http://localhost/cgi-bin/man/man2html?8+mount">mount</A></B>(8), большинство из которых могут запускаться
только суперпользователем.
</DL>
<A NAME="lbAF"> </A>
<H3>Пакет макросов</H3>
Новые справочные страницы должны размечаться с помощью пакета <B>groff an.tmac</B>, описанного в <B><A HREF="http://localhost/cgi-bin/man/man2html?7+man">man</A></B>(7). Данный выбор основан по большей части на
том, что большинство из существующих страниц Linux размечены с помощью этих
макросов.
<A NAME="lbAG"> </A>
<H3>Правила, касающиеся формата исходных файлов</H3>
Длина строки не должна превышать 75 символов. В некоторых почтовых клиентах
это помогает избежать переноса строк в заплатах, встроенных в письма.
<A NAME="lbAH"> </A>
<H3>Заголовок</H3>
Первой должна быть команда <B>TH</B>:
<DL COMPACT><DT><DD>
<B>.TH</B> <I>заголовок раздел дата источник раздел-руководства</I>
</DL>
Аргументы этой команды следующие:
<DL COMPACT>
<DT><I>заголовок</I><DD>
Название страницы, написанное заглавными буквами (например <I>MAN-PAGES</I>).
<DT><I>раздел</I><DD>
Номер раздела для размещения страницы (например <I>7</I>).
<DT><I>дата</I><DD>
Дата последнего значительного изменения справочной страницы (в проекте
<I>man-pages</I> необходимые обновления временных отметок выполняются
автоматически при помощи сценариев, вручную устанавливать её заплатой не
нужно). Дата должна иметь вид YYYY-MM-DD, т. е. год-месяц-день.
<DT><I>источник</I><DD>
Имя и версия проекта, который предоставляет данную страницу руководства (не
обязательно того пакета, который предоставляет саму функциональность).
<DT><I>раздел-руководства</I><DD>
Обычно этот аргумент должен оставаться пустым, т. к. значение по умолчанию и
так является подходящим.
</DL>
<A NAME="lbAI"> </A>
<H3>Разделы внутри справочной страницы</H3>
Следующий список содержит общепринятые и рекомендуемые разделы. Большинство
справочных страниц должно включать в себя по крайней мере те разделы,
которые <B>выделены полужирным</B>. При создании новой справочной страницы
размещайте разделы в порядке, указанном в списке.
<DL COMPACT><DT><DD>
<TABLE>
<TR VALIGN=top><TD><B>NAME</B></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>БИБЛИОТЕКА</TD><TD>[Обычно только в Разделах 2 и 3]<BR></TD></TR>
<TR VALIGN=top><TD><B>ОБЗОР</B></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>НАСТРОЙКА</TD><TD>[Обычно только в Разделе 4]<BR></TD></TR>
<TR VALIGN=top><TD><B>ОПИСАНИЕ</B></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>ПАРАМЕТРЫ</TD><TD>[Обычно только в Разделах 1 и 8]<BR></TD></TR>
<TR VALIGN=top><TD>КОД ЗАВЕРШЕНИЯ</TD><TD>[Обычно только в Разделах 1 и 8]<BR></TD></TR>
<TR VALIGN=top><TD>ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ</TD><TD>[Обычно только в Разделах 2 и 3]<BR></TD></TR>
<TR VALIGN=top><TD>ОШИБКИ</TD><TD>[Обычно только в Разделах 2 и 3]<BR></TD></TR>
<TR VALIGN=top><TD>СРЕДА ОКРУЖЕНИЯ</TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>ФАЙЛЫ</TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>АТРИБУТЫ</TD><TD>[Обычно только в Разделах 2 и 3]<BR></TD></TR>
<TR VALIGN=top><TD>ВЕРСИИ</TD><TD>[Обычно только в Разделах 2 и 3]<BR></TD></TR>
<TR VALIGN=top><TD>СТАНДАРТЫ</TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>ИСТОРИЯ</TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>ПРИМЕЧАНИЯ</TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>ОГОВОРКИ</TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>ОШИБКИ</TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>ПРИМЕРЫ</TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>АВТОРЫ</TD><TD>[Не рекомендуется]<BR></TD></TR>
<TR VALIGN=top><TD>ИНФОРМАЦИЯ ОБ ОШИБКАХ</TD><TD>[Не используется в справочных страницах]<BR></TD></TR>
<TR VALIGN=top><TD>АВТОРСКИЕ ПРАВА</TD><TD>[Не используется в справочных страницах]<BR></TD></TR>
<TR VALIGN=top><TD><B>СМОТРИТЕ ТАКЖЕ</B></TD><TD><BR></TD></TR>
</TABLE>
</DL>
Там, <I>где применимы обычные заголовки</I>, <I>используйте их</I>;
последовательность в подобных вещах может сделать информацию более доступной
для понимания. Но если это необходимо, вы можете создавать и свои
собственные заголовки, если они сделают текст более простым для понимания
(это может быть особенно полезным для страниц в Разделах 4 и 5). Тем не
менее, прежде чем создавать их, подумайте, нельзя ли обойтись традиционными
заголовками и просто создать свои собственные подразделы (<I>.SS</I>) в этих
разделах.
В приведённом ниже списке объясняется назначение каждого из разделов.
<DL COMPACT>
<DT><B>NAME</B><DD>
Название данной справочной страницы.
<DT><DD>
Смотрите <B><A HREF="http://localhost/cgi-bin/man/man2html?7+man">man</A></B>(7), чтобы ознакомиться с правилами написания заголовков,
которые должны идти после команды <B>.SH NAME</B>. Все слова в этой строке (в
том числе идущие сразу после «[rs]-») должны быть в нижнем регистре, за
исключением тех случаев, когда правилами языка, на котором написана
страница, или сложившейся практикой употребления технических терминов
определено иное.
<DT><B>БИБЛИОТЕКА</B><DD>
Библиотека, предоставляющая символ.
<DT><DD>
Здесь записывается общеупотребимое имя библиотеки, её имя файла (в скобках)
и, если необходимо, флаги компоновщика, необходимые для сборки программы с
этой библиотекой: (<I>libfoo</I>[, <I>-lfoo</I>]).
<DT><B>ОБЗОР</B><DD>
Краткое описание команды или интерфейса функции.
<DT><DD>
Для команд здесь приводятся синтаксис и аргументы (включая параметры);
полужирное начертание используется для текста, который должен использоваться
дословно, а курсивом обозначаются изменяемые аргументы. Необязательные
аргументы приводятся в квадратных скобках ([]), вертикальной чертой (|)
разделяются альтернативные варианты, многоточие (...) показывает
возможность повторения. Для функций приводятся все необходимые объявления
данных или директивы <B>#include</B>, после которых следует объявление функции.
<DT><DD>
Если для получения объявления функции (или переменной) из заголовочного
файла требуется определить макрос тестирования свойств, то это также
указывается в разделе ОБЗОР, как это описано в <B><A HREF="http://localhost/cgi-bin/man/man2html?7+feature_test_macros">feature_test_macros</A></B>(7).
<DT><B>КОНФИГУРАЦИЯ</B><DD>
Особенности настройки устройства.
<DT><DD>
Этот раздел, как правило, присутствует только в страницах Раздела 4.
<DT><B>ОПИСАНИЕ</B><DD>
Объяснение того, для чего предназначена программа, функция или формат.
<DT><DD>
Здесь описывается взаимодействие с файлами и стандартным потоком ввода, и
что записывается в стандартные потоки вывода или ошибок; детали внутреннего
устройства и реализации должны опускаться, если они не критичны для
понимания интерфейса; в этом разделе демонстрируется типовое использование;
информация о параметрах командной строки программы даётся в разделе
<B>ПАРАМЕТРЫ</B>.
<DT><DD>
При описании нового поведения или новых флагов системных вызовов или
библиотечных функций, уделите время тому, чтобы отметить, в какой версии
ядра или библиотеки Си было введено это изменение. Данную информацию
предпочтительнее приводить как часть списка <B>.TP</B> в следующем виде (здесь
показан новый флаг системного вызова):
<DL COMPACT><DT><DD>
<DL COMPACT>
<DT><B>XYZ_FLAG</B> (начиная с Linux 3.7)<DD>
Описание флага…
</DL>
</DL>
<DT><DD>
Включает информацию о версии, что особенно востребовано пользователями,
которые вынуждены использовать старые версии ядра или библиотеки Си (что
характерно, например, для встраиваемых систем).
<DT><B>ПАРАМЕТРЫ</B><DD>
Описание параметров командной строки и их влияния на поведение программы.
<DT><DD>
Этот раздел, как правило, содержится только в справочных страницах Разделов
1 и 8.
<DT><B>КОД ЗАВЕРШЕНИЯ</B><DD>
Перечень возможных значений кода выхода программы и ситуаций, при которых
программа возвращает данное значение кода.
<DT><DD>
Этот раздел, как правило, содержится только в справочных страницах Разделов
1 и 8.
<DT><B>ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ</B><DD>
Для страниц из Разделов 2 и 3 данный раздел содержит перечень значений,
которые библиотечные подпрограммы возвращают при их вызове, а также условия,
которые приводят к возврату этих значений.
<DT><B>ОШИБКИ</B><DD>
В справочных страницах Разделов 2 и 3 здесь описываются значения ошибок,
которые могут быть помещены в <I>errno</I>, а также приводится описание причин
возникновения этих ошибок.
<DT><DD>
Если одна и та же ошибка возникает по нескольким различным причинам,
предпочтительней для каждой из них создавать отдельную запись в списке (с
повторением имени ошибки). Такое разделение делает условия возникновения
ошибок более понятными: этот список проще читать и это позволяет для каждой
отдельной причины добавлять метаинформацию (например, номер версии ядра,
начиная с которой эти условия стали актуальными).
<DT><DD>
<I>Список ошибок должен быть в алфавитном порядке</I>.
<DT><B>ОКРУЖЕНИЕ</B><DD>
Перечень переменных окружения, влияющих на программу и оказываемый ими
эффект.
<DT><B>ФАЙЛЫ</B><DD>
Список файлов, используемых программой или функцией, таких как
конфигурационные файлы, файлы запуска и файлы, с которыми непосредственно
работает программа.
<DT><DD>
Указывайте полный путь к этим файлам, а также используйте возможность
скорректировать эти пути в процессе установки в соответствии с
предпочтениями пользователя. Многие программы по умолчанию устанавливаются в
<I>/usr/local</I>, поэтому ваша страница руководства по умолчанию должна
использовать <I>/usr/local</I> в качестве базового каталога.
<DT><B>АТРИБУТЫ</B><DD>
Общая информация о различных атрибутах функции(функций), описанной на этой
странице. Смотрите <B><A HREF="http://localhost/cgi-bin/man/man2html?7+attributes">attributes</A></B>(7) для получения дополнительных сведений.
<DT><B>ВЕРСИИ</B><DD>
Краткий обзор систем, в которых данный API функционирует по-другому или в
которых есть похожие API.
<DT><B>СТАНДАРТЫ</B><DD>
Описание любых стандартов или соглашений, относящихся к функции или команде,
речь о которой идёт на странице.
<DT><DD>
Предпочтительные обозначения для различных стандартов указаны в качестве
заголовков на странице <B><A HREF="http://localhost/cgi-bin/man/man2html?7+standards">standards</A></B>(7).
<DT><DD>
В данном разделе должны содержаться заметки о том, какому текущему стандарту
соответствует данный API.
<DT><DD>
Если API не соответствует никакому стандарту, но существует во множестве
систем, об этом также стоит упомянуть. Если вызов является специфичным для
Linux или GNU, то это тоже стоит отметить. Если он доступен только в
BSD-системах, отметьте и это.
<DT><DD>
Если данный раздел состоит только из списка стандартов (как это обычно и
бывает), завершите список точкой ([aq].[aq]).
<DT><B>ИСТОРИЯ</B><DD>
Краткие сведения о том, в каких версиях ядра Linux или glibc впервые
появился системный вызов или функция библиотеки, либо произошли существенные
изменения в их работе.
<DT><DD>
Как правило, описание каждого нового интерфейса должно включать раздел
ИСТОРИЯ в справочной странице. К сожалению, во многих справочных страницах
эта информация отсутствует (когда они были написаны, этого правила ещё не
было). Заплаты, исправляющие подобные недостатки, приветствуются, но, с
точки зрения программистов, пишущих новый код, эта информация, вероятно,
имеет значение только в том случае, если интерфейсы ядра были добавлены в
Linux 2.4 или позже (т. е. были изменены со времён Linux 2.2), а для
библиотечных функций, если изменения были добавлены начиная с glibc версии
2.1 (т. е. были изменены со времён glibc 2.0).
<DT><DD>
Справочная страница <B><A HREF="http://localhost/cgi-bin/man/man2html?2+syscalls">syscalls</A></B>(2) также содержит информацию о версиях ядра,
в которых были впервые реализованы различные системные вызовы.
Старые версии стандартов (например, SUS, SUSv2 и XPG или стандарты
реализаций SVr4 и 4.xBSD) должны упоминаться здесь, а не в разделе
СТАНДАРТЫ.
<DT><B>ЗАМЕЧАНИЯ</B><DD>
Различные замечания.
<DT><DD>
Для страниц в Разделах 2 и 3 может быть полезным создание подразделов
(<B>SS</B>), озаглавленных <I>Замечания, касающиеся Linux</I> (<I>Linux notes</I>) и
<I>Замечания по glibc</I> (<I>glibc notes</I>).
<DT><DD>
В Разделе 2 используйте заголовок <I>Отличия между библиотекой C и ядром</I>
(<I>C library/kernel differences</I>), чтобы отметить различия (если имеются)
между функциями-обёртками в библиотеке Си и интерфейсом системных вызовов,
предоставляемым самим ядром.
<DT><B>ОГОВОРКИ</B><DD>
Предупреждения о распространённых практиках неправильного использования API
пользователями, которые не являются ошибками реализации или дефектами
проектирования.
<DT><B>ДЕФЕКТЫ</B><DD>
Перечень известных ошибок, ограничений, недостатков причиняющих неудобство а
также других сомнительных свойств.
<DT><B>ПРИМЕРЫ</B><DD>
Один или несколько примеров, демонстрирующих, каким образом данная функция,
команда или файл используются.
<DT><DD>
Для получения более подробной информации о написании примеров программ
смотрите раздел <I>Примеры программ</I> далее.
<DT><B>АВТОРЫ</B><DD>
Список авторов документа или программы.
<DT><DD>
<B>Использовать раздел АВТОРЫ настоятельно не рекомендуется</B>. Лучше не
загромождать каждую страницу списком авторов (список со временем
увеличивается); если вы написали или значительно исправили страницу,
добавьте уведомление об авторском праве в виде комментария в исходный
файл. Если вы автор драйвера устройства и хотите включить адрес для отправки
сообщений об ошибках, то сделайте это в разделе ДЕФЕКТЫ.
<DT><B>ИНФОРМАЦИЯ ОБ ОШИБКАХ</B><DD>
Проект <I>man-pages</I> не использует раздел ИНФОРМАЦИЯ ОБ ОШИБКАХ в своих
страницах руководства. Вместо этого информация о том, как сообщать об
ошибках, предоставляется в разделе ВЫХОДНЫЕ ДАННЫЕ, который генерируется
сценарием. Однако, различные другие проекты используют этот
раздел. Рекомендуется размещать его ближе к концу страницы.
<DT><B>АВТОРСКИЕ ПРАВА</B><DD>
Проект <I>man-pages</I> не использует раздел АВТОРСКИЕ ПРАВА в своих страницах
руководства. Информация об авторском праве вместо этого поддерживается в
исходном коде страницы. На страницах, где этот раздел присутствует,
рекомендуется размещать его ближе к концу страницы, прямо перед разделом
СМОТРИТЕ ТАКЖЕ.
<DT><B>СМОТРИТЕ ТАКЖЕ</B><DD>
Разделённый запятыми список уместных справочных страниц, возможно, ведущих
на другие страницы или документы.
<DT><DD>
Список должен быть упорядочен по номеру раздела, а затем по алфавиту. Не
заканчивайте список точкой.
<DT><DD>
Если список <B>СМОТРИТЕ ТАКЖЕ</B> содержит много длинных имён справочных
страниц, то для улучшения визуального представления может быть полезно
воспользоваться командами <I>.ad l</I> (выровнять по левому краю, а не по
ширине) и <I>.nh</I> (отключить перенос). Предотвратить перенос слов в названиях
отдельных справочных страниц можно, добавив перед ними «[rs]%».
<DT><DD>
Учитывая распределённую, автономную природу проектов FOSS и их документации,
иногда необходимо [em] и во многих случаях желательно [em] включать в
раздел <B>СМОТРИТЕ ТАКЖЕ</B> ссылки на справочные страницы из других проектов.
</DL>
<A NAME="lbAJ"> </A>
<H2>СОГЛАШЕНИЯ О ФОРМАТИРОВАНИИ И ФОРМУЛИРОВКАХ</H2>
Следующие подразделы описывают некоторые детали соглашений, касающихся
предпочтительных вариантов форматирования и формулировок в различных
разделах справочных страниц проекта <I>man-pages</I>.
<A NAME="lbAK"> </A>
<H3>ОБЗОР</H3>
Оборачивайте прототипы функций в <I>.nf</I>/<I>.fi</I>, чтобы предотвратить переносы
строк.
В общем случае, если в разделе ОБЗОР перечислено более одного прототипа
функции, эти прототипы <I>не</I> должны разделяться пустыми строками. Однако
пустые строки могут быть добавлены (с помощью <I>.P</I>) в следующих случаях:
<DL COMPACT>
<DT>[bu]<DD>
чтобы разделять длинные списки прототипов функций на отдельные
взаимосвязанные группы (смотрите, например, <B><A HREF="http://localhost/cgi-bin/man/man2html?3+list">list</A></B>(3));
<DT>[bu]<DD>
в других случаях, когда это может улучшить читаемость.
В разделе ОБЗОР может потребоваться разделить длинные прототипы функций на
несколько строк. В таком случае отступы в строках, перенесённых на следующую
строку, расставляются по следующим правилам:
<DT>(1)<DD>
Если есть только один такой прототип, который требует переноса на следующую
строку, то добавьте отступы в перенесённую строку таким образом, чтобы при
отображении страницы на устройстве с фиксированной шириной шрифта (например,
в xterm) вторая строка начиналась прямо под началом списка аргументов в
предыдущей строке. (Исключение: можно использовать и меньшие отступы, если
это необходимо, чтобы предотвратить добавление очень длинных строк или
дополнительных переносов в случаях, когда прототипы функций очень длинные.)
Например:
<DT><DD>
<PRE>
<B>int tcsetattr(int </B><I>fd</I><B>, int </B><I>optional_actions</I><B>,</B>
<B> const struct termios *</B><I>termios_p</I><B>);</B>
</PRE>
<DT>(2)<DD>
Но если в разделе ОБЗОР переходы на новую строку требуются для нескольких
функций, и имена этих функций имеют разную длину, то выровняйте все
дополнительные строки так, чтобы они начинались с одного и того же
столбца. Это обеспечивает более приятное отображение при выводе в PDF
(поскольку в разделе ОБЗОР используется шрифт переменной ширины, в котором
пробелы отображаются как более узкие по сравнению с большинством других
символов). Например:
<DT><DD>
<PRE>
<B>int getopt(int </B><I>argc</I><B>, char * const </B><I>argv[]</I><B>,</B>
<B> const char *</B><I>optstring</I><B>);</B>
<B>int getopt_long(int </B><I>argc</I><B>, char * const </B><I>argv[]</I><B>,</B>
<B> const char *</B><I>optstring</I><B>,</B>
<B> const struct option *</B><I>longopts</I><B>, int *</B><I>longindex</I><B>);</B>
</PRE>
</DL>
<A NAME="lbAL"> </A>
<H3>ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ</H3>
Предпочтительная формулировка для описания того, какое значение
устанавливается в <I>errno</I>: «<I>errno</I> устанавливается в соответствующее
значение» («<I>errno</I> is set to indicate the error») или аналогичная. Эта
формулировка соответствует формулировке, используемой как в POSIX.1, так и
во FreeBSD.
<A NAME="lbAM"> </A>
<H3>АТРИБУТЫ</H3>
Также заметим следующее:
<DL COMPACT>
<DT>[bu]<DD>
Оборачивайте таблицы в этом разделе в <I>.ad l</I>/<I>.ad</I>, чтобы предотвратить
выравнивание по ширине, а также в <I>.nh</I>/<I>.hy</I>, чтобы предотвратить
переносы слов.
<DT>[bu]<DD>
Чтобы таблица занимала всю ширину страницы, добавьте к одному из её столбцов
(обычно к первому, хотя в некоторых случаях бывает лучше добавить к
последнему, если он содержит много текста) дескриптор формата <I>lbx</I> .
<DT>[bu]<DD>
Свободно используйте макросы <I>T{</I>/<I>T}</I>, дабы ячейки таблиц могли быть
разбиты на несколько строк (при этом учитывайте, что страницы иногда могут
отображаться на экранах шириной менее 80 столбцов).
Для примеров всего вышеперечисленного см. исходный код различных страниц.
</DL>
<A NAME="lbAN"> </A>
<H2>РУКОВОДСТВО ПО СТИЛЮ ОФОРМЛЕНИЯ</H2>
В следующих абзацах представлен предпочтительный стиль для страниц в проекте
<I>man-pages</I>. Если что-то в данном разделе описано недостаточно подробно, то
следует придерживаться рекомендаций Чикагского руководства по стилю (Chicago
Manual of Style); также постарайтесь поискать примеры для схожих ситуаций в
дереве исходных текстов проекта.
<A NAME="lbAO"> </A>
<H3>Использование гендерно-нейтральных выражений</H3>
Используйте гендерно-нейтральный язык в тексте справочных страниц насколько
это возможно. Приемлемо использовать местоимения «они», «им», «себя», «их»
(«they», «them», «themself», «their») в качестве гендерно-нейтральных
местоимений единственного числа.
<A NAME="lbAP"> </A>
<H3>Соглашения о форматировании справочных страниц, описывающих команды</H3>
Для справочных страниц, описывающих команды (как правило, в Разделах 1 и 8),
аргументы всегда указываются с помощью курсива, <I>даже в разделе ОБЗОР</I>.
Имя команды и её параметры всегда должны быть выделены полужирным.
<A NAME="lbAQ"> </A>
<H3>Соглашения по оформлению справочных страниц, описывающих функции</H3>
В справочных страницах, которые описывают функции (обычно в Разделах 2 и 3),
параметры всегда оформляются, используя курсив; <I>даже в разделе ОБЗОР</I>, где
остальная часть функции оформляется полужирным:
<B> int имя_функции(int </B><I>argc</I><B>, char **</B><I>argv</I><B>);</B>
Имена переменных, как и имена параметров, должны быть оформлены курсивом.
Любая ссылка на предмет текущей справочной страницы должна быть оформлена в
виде имени этой страницы в полужирном начертании, за которым следует пара
круглых скобок в обычном начертании. Например, на странице <B><A HREF="http://localhost/cgi-bin/man/man2html?2+fcntl">fcntl</A></B>(2)
ссылки на её тему должны выглядеть как: <B>fcntl</B>(). Рекомендуемый способ
записи этого в исходном файле:
<BR> .BR fcntl ()
(Использование такого формата записи вместо «[rs]fB...[rs]fP()» упрощает
создание инструментов разбора исходных файлов справочных страниц.)
<A NAME="lbAR"> </A>
<H3>Использование семантических переводов строк</H3>
В исходном тексте справочной страницы новые предложения должны начинаться с
новой строки, а длинные предложения должны разбиваться на строки в местах их
деления на синтаксические части (запятыми, точками с запятой, двоеточиями и
т. п.), а слишком длинные синтаксические части должны разбиваться на
границах словосочетаний. Это соглашение, иногда называемое «семантическими
переводами строк», облегчает просмотр внесённых заплат, которые зачастую
вносят изменения только в отдельные предложения или их части.
<A NAME="lbAS"> </A>
<H3>Списки</H3>
Существуют разные виды списков:
<DL COMPACT>
<DT>Помеченные абзацы<DD>
Эти списки используются для перечисления меток и их описаний. Когда метки
представляют собой константы (макросы или числа), они должны использовать
полужирное начертание. Используйте для этого макрос <B>.TP</B>.
<DT><DD>
Примером является сам данный подраздел «Помеченные абзацы».
<DT>Упорядоченные списки<DD>
Элементы этих списков предваряются номером (индексом) в круглых скобках:
(1), (2). Они представляют собой некий набор пунктов, идущих в определённом
порядке.
<DT><DD>
При наличии подпунктов они будут пронумерованы как (4.2).
<DT>Позиционные списки<DD>
Элементы этих списков предваряются номером (индексом) в квадратных скобках:
[4], [5]. Они представляют собой некие поля в наборе. В качестве начального
индекса используется:
<DL COMPACT><DT><DD>
<DL COMPACT>
<DT><B>0</B><DD>
Если список описывает поля структуры данных Си, дабы это согласовывалось с
соглашениями, принятыми при описании массивов.
<DT><B>1</B><DD>
Если список описывает поля какого-либо файла, дабы это согласовывалось с
такими утилитами, как <B><A HREF="http://localhost/cgi-bin/man/man2html?1+cut">cut</A></B>(1).
</DL>
</DL>
<DT>Списки альтернатив<DD>
Элементы этих списков предваряются буквой в скобках: (а), (б) («(a),
(b)»). Они представляют собой набор (обычно) взаимоисключающих альтернатив.
<DT>Ненумерованные списки<DD>
Элементы этих списков предваряются символом маркера (<B>[rs][bu]</B>). Все
списки, которые не вписываются в другие типы, обычно покрываются этим.
<DT>Нумерованные заметки<DD>
Эти заметки на самом деле не то чтобы являются списками, но их синтаксис
идентичен «позиционным спискам».
Между символом начала пункта списка и самим его содержимым всегда должно
быть ровно два пробела. За исключением «помеченных абзацев», которые
используют стандартные правила расстановки отступов.
</DL>
<A NAME="lbAT"> </A>
<H3>Общие соглашения по оформлению</H3>
Параграфы должны разделяться соответствующими маркерами (обычно <I>.P</I> или
<I>.IP</I>). <I>Не</I> разделяйте параграфы пустыми строками, так как это может
привести к плохому отображению в некоторых выходных форматах (в частности,
PostScript и PDF).
Имена файлов (а также пути или упоминания в тексте заголовочных файлов)
всегда должны быть выделены курсивом (например, <I><<A HREF="file:/usr/include/stdio.h">stdio.h</A>></I>), за
исключением раздела ОБЗОР, где включаемые файлы должны быть выделены
полужирным (например, <B>#include <<A HREF="file:/usr/include/stdio.h">stdio.h</A>></B>). Когда речь идёт о
стандартных заголовочных файлах, используйте угловые скобки при их
включении, как это обычно делается в Си (например, <I><<A HREF="file:/usr/include/stdio.h">stdio.h</A>></I>).
Специальные макросы, которые обычно находятся в верхнем регистре, выделяются
полужирным (например, <B>MAXINT</B>). Исключение: не выделяйте полужирным NULL.
В списке, при перечислении кодов ошибок, коды оформляют полужирным (в этом
списке обычно используют макрос <B>.TP</B>).
Полные команды, если они длинные, должны записываться в виде отдельной
строки с отступом и пустыми строками перед и после команды, например:
man 7 man-pages
Если команда короткая, то её можно включить прямо в текст, выделив курсивом,
например: <I>man 7 man-pages</I>. В таком случае, вероятно, будет лучше, по
необходимости, использовать неразрывные пробелы (<B>[rs][ti]</B>). Параметры
команд также должны выделяться курсивом (например, <I>-l</I>).
Выражения, если они не записаны отдельной строкой с отступом, должны
выделяться курсивом. Для их записи также может быть уместно использовать
неразрывные пробелы, когда эти выражения встроены в обычный текст.
В примерах, демонстрирующих сеанс оболочки, пользовательский ввод должен
быть выделен полужирным, например:
$ <B>date</B>
Thu Jul 7 13:01:27 CEST 2016
Все упоминания других справочных страниц должны выделяться полужирным, и
после них <I>всегда</I> должен идти номер раздела в обычном начертании и без
пробелов (например, <B><A HREF="http://localhost/cgi-bin/man/man2html?2+intro">intro</A></B>(2)). В исходном файле это лучше записывать так:
<BR> .BR intro (2)
(включение номера раздела в перекрёстных ссылках позволяет таким
инструментам, как <B><A HREF="http://localhost/cgi-bin/man/man2html?1+man2html">man2html</A></B>(1), создавать страницы с правильными
гиперссылками)
Управляющие символы следует выделять полужирным, без кавычек; например:
<B>[ha]X</B>.
<A NAME="lbAU"> </A>
<H3>Орфография</H3>
Начиная с выпуска 2.59, проект <I>man-pages</I> следует американским правилам
орфографии (ранее использовалась произвольная смесь британской и
американской орфографии); при написании всех новых страниц, а также при
правке существующих придерживайтесь этого соглашения.
Кроме известных различий в написании, есть несколько других тонкостей,
которые следует учитывать:
<DL COMPACT>
<DT>[bu]<DD>
Американский вариант английского языка имеет обыкновение использовать формы
«backward» (назад), «upward» (вверх), «toward» (к) и т. д., а в британском
варианте это «backwards», «upwards», «towards» и т. д.
<DT>[bu]<DD>
Мнения разделились по поводу написания «acknowledgement» или
«acknowledgment». Последнее более распространено, но не является абсолютно
общепринятым в американском английском. POSIX и лицензия BSD используют
первое написание. В проекте Linux man-pages мы используем «acknowledgement».
</DL>
<A NAME="lbAV"> </A>
<H3>Номера версий BSD</H3>
Классической схемой обозначения версий BSD является <I>x.yBSD</I>, где <I>x.y</I> -
номер версии (например, 4.2BSD). Избегайте написания в стиле <I>BSD 4.3</I>.
<A NAME="lbAW"> </A>
<H3>Употребление прописных букв</H3>
В заголовках разделов («SS») начинайте первое слово заголовка с заглавной
буквы, а остальные буквы должны быть строчными, если обратного не требуют
правила вашего языка (например, в именах собственных) или языка
программирования (например, в именах идентификаторов). Например:
.SS Юникод в системе Linux
<A NAME="lbAX"> </A>
<H3>Отступы при определении структур, содержимого журналов сеансов оболочек и т. п.</H3>
При включении определений структур, журналов сеансов оболочек и т. п. в
основной текст, нужно использовать отступ в 4 пробела (т. е. заключить блок
в <I>.in +4n</I> и <I>.in</I>), задать им формат с помощью макросов <I>.EX</I> и <I>.EE</I>
и окружить их подходящими маркерами параграфа (<I>.P</I> или <I>.IP</I>). Например:
.P
.in +4n
.EX
int
main(int argc, char *argv[])
{
<BR> return 0;
}
.EE
.in
.P
<A NAME="lbAY"> </A>
<H3>Предпочтительные термины</H3>
В следующей таблице перечислены некоторые предпочтительные термины, для
использования в справочных страницах, главным образом, для
непротиворечивости информации на страницах.
<TABLE>
<TR VALIGN=top><TD>Термин (перевод)</TD><TD>Не используйте</TD><TD>Примечания<BR></TD></TR>
<TR VALIGN=top><TD></TD></TR>
<TR VALIGN=top><TD>bit mask (битовая маска)</TD><TD>bitmask</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>built-in (встроенный)</TD><TD>builtin</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>Epoch (Эпоха)</TD><TD>epoch</TD><TD>
Эпоха UNIX (00:00:00, 1 января 1970 UTC)
<BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>filename (имя файла)</TD><TD>file name</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>filesystem (файловая система)</TD><TD>file system</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>hostname (имя узла)</TD><TD>host name</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>inode</TD><TD>i-node</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>lowercase (строчные)</TD><TD>lower case, lower-case</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>nonzero (ненулевой)</TD><TD>non-zero</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>pathname (путь)</TD><TD>path name</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>pseudoterminal (псевдо-терминал)</TD><TD>pseudo-terminal</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>privileged port (привилегированный порт)</TD><TD>
reserved port,
system port
</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>real-time (в реальном времени)</TD><TD>
realtime,
real time
</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>run time (время исполнения)</TD><TD>runtime</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>saved set-group-ID (сохранённый set-group-ID)</TD><TD>
saved group ID,
saved set-GID
</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>saved set-user-ID (сохранённый set-user-ID)</TD><TD>
saved user ID,
saved set-UID
</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>set-group-ID</TD><TD>set-GID, setgid</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>set-user-ID</TD><TD>set-UID, setuid</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>superuser (суперпользователь)</TD><TD>
super user,
super-user
</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>superblock (суперблок)</TD><TD>
super block,
super-block
</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>symbolic link (символьная ссылка)</TD><TD>symlink</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>timestamp (метка времени)</TD><TD>time stamp</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>timezone (часовой пояс)</TD><TD>time zone</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>uppercase (прописные)</TD><TD>upper case, upper-case</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>usable (доступный для использования)</TD><TD>useable</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>user space (пространство пользователя)</TD><TD>userspace</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>username (имя пользователя)</TD><TD>user name</TD><TD><BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>x86-64</TD><TD>x86_64</TD><TD>
Кроме случая, когда ссылаются на результат «uname -m» или подобных
<BR></TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>zeros (нули)</TD><TD>zeroes</TD><TD><BR></TD><TD><BR></TD></TR>
</TABLE>
Смотрите также <I>Дефисы в составных терминах</I> далее.
<A NAME="lbAZ"> </A>
<H3>Термины, которых следует избегать</H3>
В следующей таблице перечислены некоторые термины, которые лучше не
использовать в справочных страницах и предлагаемые им альтернативы,
использование которых поможет избежать противоречий между справочными
страницами.
<TABLE>
<TR VALIGN=top><TD>Не используйте</TD><TD>Следует использовать</TD><TD>Примечания<BR></TD></TR>
<TR VALIGN=top><TD></TD></TR>
<TR VALIGN=top><TD>32bit</TD><TD>32-bit (32-битный)</TD><TD>
то же с 8-bit, 16-bit и т. п.
<BR></TD></TR>
<TR VALIGN=top><TD>current process (текущий процесс)</TD><TD>calling process (вызывающий процесс)</TD><TD>
Частая ошибка программистов ядра, когда они пишут справочные страницы
<BR></TD></TR>
<TR VALIGN=top><TD>manpage</TD><TD>
man page, manual page (справочная страница)
</TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>minus infinity (минус бесконечность)</TD><TD>negative infinity (отрицательная бесконечность)</TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>non-root (не root)</TD><TD>unprivileged user (непривилегированный пользователь)</TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>non-superuser (не суперпользователь)</TD><TD>unprivileged user (непривилегированный пользователь)</TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>nonprivileged</TD><TD>unprivileged (непривилегированный)</TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>OS</TD><TD>operating system (операционная система)</TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>plus infinity (плюс бесконечность)</TD><TD>positive infinity (положительная бесконечность)</TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>pty</TD><TD>pseudoterminal (псевдо-терминал)</TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>tty</TD><TD>terminal (терминал)</TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>Unices</TD><TD>UNIX systems (системы UNIX)</TD><TD><BR></TD></TR>
<TR VALIGN=top><TD>Unixes</TD><TD>UNIX systems (системы UNIX)</TD><TD><BR></TD></TR>
</TABLE>
<A NAME="lbBA"> </A>
<H3>Торговые марки</H3>
При упоминании торговых марок соблюдайте правильное написание с соблюдением
регистра. Вот список правильного написания различных торговых марок, которые
иногда указывают неправильно:
<DL COMPACT>
<DT><DD>
<TABLE>
<TR VALIGN=top><TD>DG/UX<BR></TD></TR>
<TR VALIGN=top><TD>HP-UX<BR></TD></TR>
<TR VALIGN=top><TD>UNIX<BR></TD></TR>
<TR VALIGN=top><TD>UnixWare<BR></TD></TR>
</TABLE>
</DL>
<A NAME="lbBB"> </A>
<H3>NULL, NUL, указатель null и байт null</H3>
<I>Указатель null</I> или <I>нулевой указатель</I> (<I>null pointer</I>) — это
указатель, который ни на что не указывает и, как правило, обозначается
константой <I>NULL</I>. С другой стороны, <I>NUL</I> представляет собой <I>байт null</I>
или <I>нулевой байт</I> (<I>null byte</I>), байт со значением 0, который в Си
представляется символьной константой <I>[aq][rs]0[aq]</I>.
Данный указатель лучше называть «указатель null» (null pointer) или «нулевой
указатель», или просто «NULL»; избегайте написания «указатель NULL» (NULL
pointer).
Для описания байта используйте «байт null» (null byte). Избегайте написания
«NUL», так как такое наименование слишком просто спутать с «NULL». Также
избегайте терминов «байт ноль» («zero byte») и «нулевой символ» (null
character). Байт, которым заканчиваются строки в Си, нужно описывать как
«завершающий байт null» (terminating null byte); про строки можно сказать
как «завершающиеся null» (null-terminated), но не используйте «завершающиеся
NUL» (NUL-terminated).
<A NAME="lbBC"> </A>
<H3>Гиперссылки</H3>
Для указания гиперссылок используйте пару макросов <I>.UR</I>/<I>.UE</I> (смотрите
<B><A HREF="http://localhost/cgi-bin/man/man2html?7+groff_man">groff_man</A></B>(7)). Это создаст корректные гиперссылки, которые можно
использовать при просмотре в браузере; например так:
BROWSER=firefox man -H имя-страницы
<A NAME="lbBD"> </A>
<H3>Использование сокращений e.g. (напр.), i.e. (т. е.), a.k.a. (также известный как) и т. п.</H3>
Обычно лучше не использовать такие сокращения, как «e.g.», «i.e.», «etc.»,
«cf.» и «a.k.a.», а писать слова полностью («for example» (например), «that
is» (то есть), «and so on» (и так далее), «compare to» (в сравнении с),
«also known as» (также известный как)).
Единственное местом, где подобные сокращения могут быть уместны — это
<I>короткие</I> отступления в скобках (т. е. как вот это).
Всегда указывайте точки в подобных аббревиатурах. Также после «e.g.» и
«i.e.» всегда ставится запятая. Примечание переводчика: в русскоязычных
справочных страницах после каждой точки в «т. е.», «и т. д.» и
т. п. ставится пробел; кроме того сокращение «напр.» для «например» не
используется.
<A NAME="lbBE"> </A>
<H3>Длинное тире</H3>
Добавлять в текст длинное тире [em] глиф, которым выделено данное
уточнение, [em] в *roff следует с помощью макроса «[rs][em]» (в
ASCII-терминалах, тире обычно отображается в виде двух чёрточек, но в других
типографских контекстах оно может выглядеть как простое длинное тире). Тире
должно (прим. пер.: в англоязычных справочных страницах) записываться <I>без</I>
пробелов до или после.
<A NAME="lbBF"> </A>
<H3>Дефисы в составных терминах</H3>
Составные термины пишутся через дефис при использовании в качестве
определителя (т. е. для уточнения последующего существительного). Примеры:
<DL COMPACT>
<DT><DD>
<TABLE>
<TR VALIGN=top><TD>32-bit value (32-битное значение)<BR></TD></TR>
<TR VALIGN=top><TD>command-line argument (аргумент командной строки)<BR></TD></TR>
<TR VALIGN=top><TD>floating-point number (число с плавающей запятой)<BR></TD></TR>
<TR VALIGN=top><TD>run-time check (проверка времени выполнения)<BR></TD></TR>
<TR VALIGN=top><TD>user-space function (функция пользовательского пространства)<BR></TD></TR>
<TR VALIGN=top><TD>wide-character string (широкосимвольная строка)<BR></TD></TR>
</TABLE>
</DL>
<A NAME="lbBG"> </A>
<H3>Постановка дефиса с multi, non, pre, re, sub и т. п.</H3>
Общая тенденция в современном английском языке состоит в том, чтобы не
ставить дефисы после префиксов «multi», «non», «pre», «re», «sub» и т. д. В
справочных страницах, в основном, нужно следовать этому правилу, когда эти
префиксы используются в естественных английских конструкциях с простыми
суффиксами. В следующем списке приведены некоторые примеры правильного
написания:
<DL COMPACT>
<DT><DD>
<TABLE>
<TR VALIGN=top><TD>interprocess (межпроцессный)<BR></TD></TR>
<TR VALIGN=top><TD>multithreaded (многопоточный)<BR></TD></TR>
<TR VALIGN=top><TD>multiprocess (многопроцессный)<BR></TD></TR>
<TR VALIGN=top><TD>nonblocking (неблокирующий)<BR></TD></TR>
<TR VALIGN=top><TD>nondefault (нестандартный)<BR></TD></TR>
<TR VALIGN=top><TD>nonempty (непустой)<BR></TD></TR>
<TR VALIGN=top><TD>noninteractive (неинтерактивный)<BR></TD></TR>
<TR VALIGN=top><TD>nonnegative (неотрицательный)<BR></TD></TR>
<TR VALIGN=top><TD>nonportable (непереносимый)<BR></TD></TR>
<TR VALIGN=top><TD>nonzero (ненулевой)<BR></TD></TR>
<TR VALIGN=top><TD>preallocated (предварительно выделенный)<BR></TD></TR>
<TR VALIGN=top><TD>precreate (предварительно создать)<BR></TD></TR>
<TR VALIGN=top><TD>prerecorded (предварительно записанный)<BR></TD></TR>
<TR VALIGN=top><TD>reestablished (восстановленный)<BR></TD></TR>
<TR VALIGN=top><TD>reinitialize (переинициализировать)<BR></TD></TR>
<TR VALIGN=top><TD>rearm (переустановить)<BR></TD></TR>
<TR VALIGN=top><TD>reread (перечитать)<BR></TD></TR>
<TR VALIGN=top><TD>subcomponent (подкомпонент)<BR></TD></TR>
<TR VALIGN=top><TD>subdirectory (подкаталог)<BR></TD></TR>
<TR VALIGN=top><TD>subsystem (подсистема)<BR></TD></TR>
</TABLE>
Дефисы должны быть сохранены после префиксов для нестандартных английских
слов, торговых марок, имён собственных, акронимов или составных
терминов. Несколько примеров:
<DT><DD>
<TABLE>
<TR VALIGN=top><TD>non-ASCII (не-ASCII)<BR></TD></TR>
<TR VALIGN=top><TD>non-English (неанглийский)<BR></TD></TR>
<TR VALIGN=top><TD>non-NULL (не-NULL)<BR></TD></TR>
<TR VALIGN=top><TD>non-real-time (не в реальном времени)<BR></TD></TR>
</TABLE>
И напоследок заметим, что в английском «re-create» (пересоздать) и
«recreate» (развлекаться) — это два различных глагола и вы, вероятно, хотите
использовать последний.
</DL>
<A NAME="lbBH"> </A>
<H3>Вывод оптимальных глифов</H3>
Если требуется настоящий символ математического минуса (например, для чисел
(-1), перекрёстных ссылок на другие справочные страницы (<B><A HREF="http://localhost/cgi-bin/man/man2html?7+utf-8">utf-8</A></B>(7)) или
при записи параметров, которые начинаются с чёрточки (<I>ls -l</I>)),
записывайте его в исходном коде справочных страниц следующим образом:
[rs]-
Это правило применимо и для примеров кода.
Использование настоящего символа минуса служит следующим целям:
<DL COMPACT>
<DT>[bu]<DD>
Улучшение отображения на различных целевых устройствах, отличных от
терминалов ASCII, в особенности в PDF и на терминалах, поддерживающих
Unicode/UTF-8.
<DT>[bu]<DD>
Создание глифов, которые при копировании из готовых страниц будут давать
настоящие знаки минус при вставке в терминал.
Чтобы получить одинарные кавычки, которые хорошо отображаются и в ASCII, и в
UTF-8, используйте «[rs][aq]» («apostrophe quote», «апострофная кавычка»);
например:
[rs][aq]C[rs][aq]
где <I>C</I> — символ в кавычках. Это правило применимо и для символьных
констант в примерах кода.
Когда требуется правильно отображаемый символ карет ([ha]), который будет
хорошо смотреться как в терминале, так и в PDF, используйте «\[ha]». Это
особенно важно в примерах кода, чтобы получить красивые символы циркумфлекса
при выводе в PDF.
Использование голого символа тильды «[ti]» приводит к плохому отображению в
PDF. Вместо этого используйте «\[ti]». Это также особенно важно в примерах
кода, чтобы получить красивые символы тильды при выводе в PDF.
</DL>
<A NAME="lbBI"> </A>
<H3>Примеры программ и сценариев оболочки</H3>
Справочные страницы могут включать примеры программ, демонстрирующие
использование системных вызовов или библиотечных функций. При этом нужно
учитывать ряд условий:
<DL COMPACT>
<DT>[bu]<DD>
Примеры программ должны быть написаны на языке Си.
<DT>[bu]<DD>
Примеры программ необходимы и полезны лишь в тех случаях, когда они
демонстрируют что-то сверх того, что может быть легко представлено в
текстовом описании командного интерфейса. Примеры программ, которые не
показывают ничего кроме вызова функции, как правило, обладают незначительной
полезностью.
<DT>[bu]<DD>
В идеале примеры программ должны быть краткими (например, хороший пример
зачастую можно уложить в менее чем 100 строк кода), хотя в некоторых случаях
могут потребоваться и более длинные программы, дабы должным образом
проиллюстрировать использование API.
<DT>[bu]<DD>
Выразительный код приветствуется.
<DT>[bu]<DD>
Комментарии должны быть добавлены там, где они полезны. Полные предложения в
отдельных комментариях должны завершаться точкой. Точки обычно следует
опускать в «комментариях-метках» (т. е. комментариях, размещённых на той же
строке кода); такие комментарии обычно представляют из себя лишь краткие
фразы, а не полные предложения.
<DT>[bu]<DD>
В примерах программ должна быть реализована проверка ошибок после системных
вызовов и вызовов библиотечных функций.
<DT>[bu]<DD>
Примеры программ должны быть полными и компилироваться без предупреждений
при использовании <I>cc -Wall</I>.
<DT>[bu]<DD>
Там, где это возможно и целесообразно, примеры программ должны позволять
экспериментировать с собой, изменяя своё поведение в зависимости от входных
параметров (в идеале от параметров командной строки или получаемых
программой через стандартный ввод).
<DT>[bu]<DD>
Примеры программ должны быть написаны в стиле Кернигана и Ритчи (Kernighan
and Ritchie), с отступами в 4 пробела. (Избегайте использования символа
табуляции в исходном коде!) Следующие команды могут быть использованы для
форматирования исходного кода в что-то близкое к предпочтительному стилю:
<DT><DD>
indent -npro -kr -i4 -ts4 -sob -l72 -ss -nut -psl prog.c
<DT>[bu]<DD>
Ради единообразия и удобства восприятия все программы в примерах должны
завершаться с использованием одного из следующих вариантов:
<DT><DD>
exit(EXIT_SUCCESS);
exit(EXIT_FAILURE);
<DT><DD>
Избегайте использования следующих форм завершения программы:
<DT><DD>
exit(0);
<A HREF="http://localhost/cgi-bin/man/man2html?1+exit">exit</A>(1);
return n;
<DT>[bu]<DD>
Если перед исходным кодом программы имеется обширный пояснительный текст,
выделите исходный код с помощью заголовка подраздела «<I>Исходный код программы</I>» (<I>Program source</I>), как показано ниже:
<DT><DD>
.SS Исходный код программы
<DT><DD>
Всегда делайте это, если пояснительный текст включает примеры вывода в
терминал.
Если вы включаете журнал вывода в терминал, демонстрирующий использование
программы или системной функции:
<DT>[bu]<DD>
Поместите журнал вывода перед листингом с кодом программы.
<DT>[bu]<DD>
Выделите журнал вывода отступом в четыре пробела.
<DT>[bu]<DD>
Выделите полужирным вводимый пользователем текст, чтобы отличить его от
вывода системы.
Ознакомиться с тем, как должны выглядеть примеры программ Вы можете,
прочитав <B><A HREF="http://localhost/cgi-bin/man/man2html?2+wait">wait</A></B>(2) и <B><A HREF="http://localhost/cgi-bin/man/man2html?2+pipe">pipe</A></B>(2).
</DL>
<A NAME="lbBJ"> </A>
<H2>ПРИМЕРЫ</H2>
В качестве канонического примера того, как должны выглядеть страницы в
пакете <I>man-pages</I>, смотрите <B><A HREF="http://localhost/cgi-bin/man/man2html?2+pipe">pipe</A></B>(2) и <B><A HREF="http://localhost/cgi-bin/man/man2html?2+fcntl">fcntl</A></B>(2).
<A NAME="lbBK"> </A>
<H2>СМОТРИТЕ ТАКЖЕ</H2>
<B><A HREF="http://localhost/cgi-bin/man/man2html?1+man">man</A></B>(1), <B><A HREF="http://localhost/cgi-bin/man/man2html?1+man2html">man2html</A></B>(1), <B><A HREF="http://localhost/cgi-bin/man/man2html?7+attributes">attributes</A></B>(7), <B><A HREF="http://localhost/cgi-bin/man/man2html?7+groff">groff</A></B>(7), <B><A HREF="http://localhost/cgi-bin/man/man2html?7+groff_man">groff_man</A></B>(7),
<B><A HREF="http://localhost/cgi-bin/man/man2html?7+man">man</A></B>(7), <B><A HREF="http://localhost/cgi-bin/man/man2html?7+mdoc">mdoc</A></B>(7)
<P>
<A NAME="lbBL"> </A>
<H2>ПЕРЕВОД</H2>
Русский перевод этой страницы руководства разработал(и)
aereiae <<A HREF="mailto:[email protected]">[email protected]</A>>,
Alexey <<A HREF="mailto:[email protected]">[email protected]</A>>,
Azamat Hackimov <<A HREF="mailto:[email protected]">[email protected]</A>>,
Dmitriy S. Seregin <<A HREF="mailto:[email protected]">[email protected]</A>>,
Dmitry Bolkhovskikh <<A HREF="mailto:[email protected]">[email protected]</A>>,
ITriskTI <<A HREF="mailto:[email protected]">[email protected]</A>>,
Max Is <<A HREF="mailto:[email protected]">[email protected]</A>>,
Yuri Kozlov <<A HREF="mailto:[email protected]">[email protected]</A>>,
Иван Павлов <<A HREF="mailto:[email protected]">[email protected]</A>>,
Малянов Евгений Викторович <<A HREF="mailto:[email protected]">[email protected]</A>>,
Kirill Rekhov <<A HREF="mailto:[email protected]">[email protected]</A>>
и
Alexander Golubev <<A HREF="mailto:[email protected]">[email protected]</A>>
<P>
Этот перевод является свободной программной документацией; он распространяется
на условиях общедоступной лицензии GNU (GNU General Public License - GPL,
версии 3 или более поздней) в отношении
авторского права, но БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ.
<P>
Если вы обнаружите какие-либо ошибки в переводе этой страницы руководства, пожалуйста,
сообщите об этом разработчику(ам) по его(их) адресу(ам) электронной почты или по адресу
списка рассылки русских переводчиков
<P>
<HR>
<A NAME="index"> </A><H2>Index</H2>
<DL>
<DT><A HREF="#lbAB">НАИМЕНОВАНИЕ</A><DD>
<DT><A HREF="#lbAC">ОБЗОР</A><DD>
<DT><A HREF="#lbAD">ОПИСАНИЕ</A><DD>
<DL>
<DT><A HREF="#lbAE">Разделы справочных страниц</A><DD>
<DT><A HREF="#lbAF">Пакет макросов</A><DD>
<DT><A HREF="#lbAG">Правила, касающиеся формата исходных файлов</A><DD>
<DT><A HREF="#lbAH">Заголовок</A><DD>
<DT><A HREF="#lbAI">Разделы внутри справочной страницы</A><DD>
</DL>
<DT><A HREF="#lbAJ">СОГЛАШЕНИЯ О ФОРМАТИРОВАНИИ И ФОРМУЛИРОВКАХ</A><DD>
<DL>
<DT><A HREF="#lbAK">ОБЗОР</A><DD>
<DT><A HREF="#lbAL">ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ</A><DD>
<DT><A HREF="#lbAM">АТРИБУТЫ</A><DD>
</DL>
<DT><A HREF="#lbAN">РУКОВОДСТВО ПО СТИЛЮ ОФОРМЛЕНИЯ</A><DD>
<DL>
<DT><A HREF="#lbAO">Использование гендерно-нейтральных выражений</A><DD>
<DT><A HREF="#lbAP">Соглашения о форматировании справочных страниц, описывающих команды</A><DD>
<DT><A HREF="#lbAQ">Соглашения по оформлению справочных страниц, описывающих функции</A><DD>
<DT><A HREF="#lbAR">Использование семантических переводов строк</A><DD>
<DT><A HREF="#lbAS">Списки</A><DD>
<DT><A HREF="#lbAT">Общие соглашения по оформлению</A><DD>
<DT><A HREF="#lbAU">Орфография</A><DD>
<DT><A HREF="#lbAV">Номера версий BSD</A><DD>
<DT><A HREF="#lbAW">Употребление прописных букв</A><DD>
<DT><A HREF="#lbAX">Отступы при определении структур, содержимого журналов сеансов оболочек и т. п.</A><DD>
<DT><A HREF="#lbAY">Предпочтительные термины</A><DD>
<DT><A HREF="#lbAZ">Термины, которых следует избегать</A><DD>
<DT><A HREF="#lbBA">Торговые марки</A><DD>
<DT><A HREF="#lbBB">NULL, NUL, указатель null и байт null</A><DD>
<DT><A HREF="#lbBC">Гиперссылки</A><DD>
<DT><A HREF="#lbBD">Использование сокращений e.g. (напр.), i.e. (т. е.), a.k.a. (также известный как) и т. п.</A><DD>
<DT><A HREF="#lbBE">Длинное тире</A><DD>
<DT><A HREF="#lbBF">Дефисы в составных терминах</A><DD>
<DT><A HREF="#lbBG">Постановка дефиса с multi, non, pre, re, sub и т. п.</A><DD>
<DT><A HREF="#lbBH">Вывод оптимальных глифов</A><DD>
<DT><A HREF="#lbBI">Примеры программ и сценариев оболочки</A><DD>
</DL>
<DT><A HREF="#lbBJ">ПРИМЕРЫ</A><DD>
<DT><A HREF="#lbBK">СМОТРИТЕ ТАКЖЕ</A><DD>
<DT><A HREF="#lbBL">ПЕРЕВОД</A><DD>
</DL>
<HR>
This document was created by
<A HREF="http://localhost/cgi-bin/man/man2html">man2html</A>,
using the manual pages.<BR>
Time: 03:44:57 GMT, January 20, 2025
</BODY>
</HTML>
man-pages.7.po
(text/x-gettext-translation, 182.1 KB) - not displayed