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

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

Стало ясно, что для сохранения подобия UNIX-систем нужна стандартизация, и такая работа сейчас ведется.

Со временем не только стандарты двигались вперед, но и ОС Linux с впечатляющей скоростью совершенствовалась сообществом, поддержанным коммерческими организациями, такими как Red Hat и Canonical, и даже разработчиками не-Linux, например, корпорацией IBM. По мере развития Linux наряду с разработкой коллекции компиляторов gcc не только следила за соответствующими стандартами, но и определяла новые стандарты, если существующие оказывались неэффективными. В действительности по мере того, как ОС Linux и связанные с нею программные средства и утилиты становились все более популярными, разработчики UNIX-систем начали вносить изменения в свои продукты, чтобы сделать их более совместимыми с ОС Linux.

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

В особенности мы коснемся следующих тем:

□ стандарт языка программирования С;

□ стандарты UNIX, в особенности POSIX, разрабатываемые IEEE, и стандарт Single UNIX Specification, разработанный Open Group;

□ разработка Free Standards Group, в особенности Linux Standard Base, в которой определен макет стандартной файловой системы Linux.

Хорошей отправной точкой для знакомства со стандартами, относящимися к ОС Linux, служит стандарт Linux Standard Base (LSB), который можно найти на Web- сайте Linux Foundation по адресу http://www.linux-foundation.org/.

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

Язык программирования С — de facto язык программирования ОС Linux, поэтому, для того чтобы писать программы на С для Linux, необходимо немного разобраться в его истоках, узнать, как менялся язык, и, что особенно важно понять, как проверяются программы на соответствие стандартам.

Тем, кто не слишком любит историю, не стоит беспокоиться: эта книга о программировании, а не об истории, поэтому обзор будет очень кратким.

Язык программирования С появился в начале 1970-х годов и был основан отчасти на более раннем языке программирования BCPL и расширениях для языка В. Деннис Ритчи (Dennis М. Ritchie) написал руководство пользователя для языка в 1974 г., и примерно в это же время С был использован как язык программирования для переработки ядра UNIX на компьютерах PDP-11. В 1978 г. Брайан Керниган (Brian W. Kernighan) и Ритчи написали классическое руководство по, языку "The С Programming Language" ("Язык программирования С").

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

В 1983 г. ANSI (American National Standards Institute, Американский институт стандартов) основал комитет стандартов X3J11 для разработки четкого и строгого определения языка. Попутно обе организации вносили в язык незначительные изменения, в особенности придавая ему долгожданную способность объявлять типы параметров, но в основном комитет просто вносил ясность и логическое обоснование существующего определения того, что составляло общеупотребительный вариант языка. Окончательный стандарт был опубликован в 1989 г. как ANSI Standard Programming Language С, X3.159-1989 или более кратко C89, иногда именуемый C90. (Этот последний превратился в стандарт ISO/IEC 9899:1990, Programming Languages — С. Оба стандарта формально идентичны.)

Как и для большинства стандартов, публикация не закончила работу комитета, который продолжал устранять некоторые неточности, обнаруженные в спецификации, и в 1993 г. начал работу над новой версией стандарта, названного C9X. Комитет также публиковал, незначительные корректировки и обновления существующего стандарта в 1994-1996 гг.

Новая версия стандарта была сделана в 1990 гг. и официально стала стандартом С99; она была принята ISO как стандарт ISO/IEC 9899:1999. До сих пор существует работающий комитет J11, который следит за стандартизацией языка С и его библиотек, но теперь он работает под управлением группы International Committee for Information Technology Standards (Международный комитет по промышленным стандартам в сфере информационных технологий). Дополнительную информацию о работе по стандартизации С см. на Web-сайте http://j11.incits.org/.

После разработки редактора Emacs (да, мы любим Emacs) следующим важным достижением проекта GNU, как упоминалось в главе 1, стал полностью бесплатный компилятор С, gcc, первая официальная версия которого была выпущена в 1987 г.

Первоначально имя gcc расшифровывалось как GNU С Compiler (компилятор С проекта GNU), но, поскольку базовая рабочая среда компилятора теперь поддерживает много других языков программирования, таких как С++, Objective-C, FORTRAN, Java и Ada, а также библиотеки для этих языков, определение было заменено на более подходящее GNU Compiler Collection (коллекция компиляторов GNU).

gcc всегда был и похоже останется стандартным компилятором для Linux и С или С++, основного языка для написания программ в ОС Linux. Исходную страницу gcc можно найти по адресу http://gcc.gnu.org/.

Компилятор С GNU всегда хорошо отслеживал развитие стандарта языка С, хотя он допускает некоторые расширения языка, и, безусловно, существуют незначительные задержки, как почти у всех компиляторов, между выходом стандарта и появлением версий компиляторов, точно следующих этой спецификации. Порой происходит обратное, и gcc предвосхищает слабые изменения стандарта, что тоже может совершенно сбивать с толку. У gcc есть ряд опций командной строки и других, позволяющих задать версию стандарта языка С, которой должен соответствовать компилятор, а также ряд других опций для управления степенью придирчивости или строгости компилятора.

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

У gcc есть огромный набор опций, и здесь мы рассмотрим лишь те из них, которые считаем наиболее важными. Полный перечень опций можно найти на страницах интерактивного справочного руководства gcc. Мы также кратко обсудим некоторые опции директивы

#define

#include

Даже если вы пишете маленькую программу для личного применения, когда соответствие стандартам, возможно, не так уж важно, часто имеет смысл включить дополнительные предупреждения gcc, чтобы заставить компилятор искать ошибки в вашем коде еще до выполнения программы. Это всегда эффективнее, чем выполнять по шагам код в отладчике и недоумевать по поводу возможного места возникшей проблемы. У компилятора есть много опций, которые не ограничиваются простой проверкой на соответствие стандартам, таких, как способность обнаруживать код, который удовлетворяет стандарту, но, возможно, имеет сомнительную семантику. Например, в программе может быть такой порядок выполнения, который позволяет обращаться к переменной до ее инициализации.

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

Приведенные далее опции передаются gcc в командной строке; мы перечисляем здесь только самые важные из них.

□ 

-ansi

//

STRICT_ANSI__

□ 

-std=

 • 

с89

 • 

iso9899:1999

 • 

gnu89

Существуют константы (

#defines

□ 

__STRICT_ANSI__

-ansi

□ 

_POSIX_C_SOURCE=2

□ 

_BSD_SOURCE

□ 

_GNU_SOURCE

Эти опции передаются компилятору из командной строки. И снова мы перечислим лишь основные, полный список можно найти в интерактивном справочном руководстве gcc.

□ 

-pedantic

□ 

-Wformat

printf

□ 

-Wparentheses

□ 

-Wswitch-default

default

switch

□ 

-Wunused

□ 

-Wall

W

-pedantic

Примечание

Существует еще огромное множество дополнительных опций предупреждений, все подробности см. на Web-страницах gcc. В основном мы рекомендуем применять

-Wall

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

Теперь мы собираемся подняться на уровень выше и перейти от программного кода на языке С к рассмотрению интерфейсов (системных функций), предоставляемых операционной системой. У этого уровня стандартизации есть разные составляющие: функции, предоставляемые библиотеками, и системные вызовы, реализованные операционной системой на низком уровне. И у тех, и у других есть два уровня детализации: какие интерфейсы представлены и определение того, что делает каждый интерфейс.

Определяющий документ в этой области для ОС Linux — Linux Standards Base (LSB, стандарты операционных систем на базе Linux), который можно найти на Web-сайтах http://mvw.linuxbase.org или http://www.linux-foundation.org/en/LSB. Уже выпущено несколько версий стандартов, и работа продолжается.

Список дистрибутивов, прошедших сертификацию, можно найти по адресу http://www.linux-foundation.org/en/Products. Сертифицированы разные версии Red Hat, SUSE и Ubuntu, но помните о том, что после выпуска дистрибутива до момента сертификации должно пройти некоторое время. На Web-сайте есть список дистрибутивов, проходящих тестирование или только нуждающихся в некоторых обновлениях для того, чтобы пройти сертификационные испытания.

В стандарте Linux Standards Base (что касается версии 3.1) определены три области для проверки на соответствие:

□ ядро — основные библиотеки, утилиты и местонахождение ключевых компонентов файловой системы;

□ С++ — библиотеки С++;

□ рабочий стол — дополнительные файлы для установок рабочего стола, в основном разные графические библиотеки.

В спецификации нас интересует больше всего ядро.

Стандарт LSB охватывает ряд областей в собственной документации, но для определений конкретных интерфейсов также приводит ссылки на внешние стандарты. В стандарте описаны следующие области:

□ форматы объектных файлов для двоичной совместимости;

□ стандарты динамического связывания;

□ стандартные библиотеки, как базовые, так и библиотеки X Window System;

□ командная оболочка и другие программы режима командной строки;

□ среда исполнения, включая пользователей и группы;

□ инициализация системы и уровни запуска (run levels).

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

Документация Linux Standard Base определяет двумя способами интерфейсы, которые должны присутствовать. Для некоторых функций, в основном реализованных библиотекой С проекта GNU или склонных быть стандартами только для Linux, определяются и интерфейс, и его поведение. Для других интерфейсов, в особенности с UNIX-подобной основой, стандарт просто констатирует, что такой интерфейс должен присутствовать и должен вести себя, как определено другим стандартом, обычно Common Application Environment (CAE, общая прикладная среда) или еще чаще Single UNIX Specification (единая спецификация UNIX), который есть на Web-сайте Open Group http://www.opengroup.org. Некоторые части можно найти (в настоящее время требуется регистрация) по адресу http://www.unix.org/online.html.

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

ОС UNIX родилась в конце 1960 гг. в подразделении Bell Laboratories компании AT&T, когда Кен Томпсон (Ken Thompson) и Деннис Ритчи (Dennis Ritchie) написали операционную систему, первоначально предназначенную только для личного пользования, которую назвали Unics. Каким-то образом имя изменилось на UNIX. AT&T разрешила университетам брать исходный программный код для собственных разработок, и система UNIX быстро стала невероятно популярной благодаря очень четкой логической структуре и мощным идеям. Наличие исходного программного кода должно было стать существенным стимулом, т. к. позволяло программистам вносить изменения и экспериментировать.

Операционная система BSD была вариантом, который появился благодаря работе, проделанной в Университете Калифорнии в Беркли, и уделившей много внимания организации и поддержке сети.

Когда компания AT&T начала превращать UNIX в коммерческую систему, что происходило главным образом в середине 1980 гг., она называла выпуски системы UNIX System, и самым популярным был UNIX System V.

Появилось много и других вариантов, слишком много, чтобы перечислять их здесь, все они имели небольшие отличия от базовых стандартов и некоторые дополнения, поскольку компании пытались повысить стоимость продукта, создавая собственные расширения.

Все по-настоящему усложнилось, когда AT&T продала UNIX-бизнес компании Novell, которая в 1994 г. решила его завершить, и владение правами и торговыми марками стало чем-то неопределенным, послужившим предметом разных судебных разбирательств.

В 1988 г. IEEE (Institute of Electrical and Electronic Engineers, Институт инженеров по электротехнике и радиоэлектронике, http://www.ieee.org) выпустил первый набор стандартов: POSIX или IEEE 1003 — стандартов, которые задумывались как определяющая спецификация переносимого интерфейса компьютерных операционных систем. Несмотря на то, что это хороший и четко определенный стандарт, POSIX — также во многом лишь спецификация ядра с очень ограниченной областью применения.

В 1994 г. X/Open Company, не участвующая в поставках организация, выпустила более полный набор спецификаций, X/Open CAE или Common Applications Environment (общая прикладная среда), представляющий собой расширенный вариант стандартов IEEE POSIX и формально идентичный им во многих областях. Компания X/Open позже объединилась с OSF (Free Software Foundation, фонд свободного программного обеспечения) для учреждения Open Group; ее исходная Web-страница находится по адресу http://www.opengroup.org/. Стандарт CAE был исправлен и выпущен в 2002 г. как Single UNIX Specification, Version 3 (единая спецификация UNIX, версия 3), разработанный Open Group.

Именно на эту спецификацию чаще всего ссылается база стандартов Linux.

Примечание

Следует отметить, что "Linux" — это торговая марка, принадлежащая Линусу Торвальдсу (Linus Torvalds). См. http://www.linuxmark.org/.

Довольно об истории создания стандартов. Что означает для людей, пишущих программы на языке С (или С++), требование их переносимости?

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

Во-вторых, что труднее, следует убедиться в том, что поведение используемой вами функции включено в стандарт, и вы не полагаетесь на поведение, не описанное в стандарте. Возможно, для этого вам придется обратиться к стандарту Single UNIX Specification, если применение функции не определено в стандарте LSB. Очень хороший способ проверки неопределенного или потенциально ошибочного поведения — обращение к интерактивному руководству Linux. На многих его страницах есть раздел "BUGS" ("Ошибки"), представляющий собой неоценимый источник информации о том, где в ОС Linux конкретный вызов не в полной мере реализует стандарты или где существуют дефекты и нелепости в поведении.

Этот раздел стандарта точен, краток и понятен. Далее перечислены некоторые требования стандарта.

□ Спецификация требует для получения подробных сведений о пользователе никогда не читать напрямую такие файлы, как /etc/passwd, а всегда применять вызовы стандартной библиотеки, например

getpwent

passwd

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

□ В стандарте также указано, что ID, меньшие 100, — системные учетные записи, диапазон 100-499 занимают системные администраторы и постустановочные сценарии, и, наконец, ID с номерами 500 и большими предназначены для учетных записей обычных пользователей.

Как правило, большинство программистов Linux должно знать о требованиях стандартов, касающихся пользователей.

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

Система Linux унаследовала от UNIX-подобных операционных систем идею уровней запуска или выполнения, определяющих сервисы, постоянно выполняющиеся в системе. В табл. 18.1 приведены стандартные определения для ОС Linux.

Таблица 18.1

Стандарт LSB приводит эти уровни, но не требует их обязательного использования, хотя они и очень распространены.

Сопровождает уровни запуска набор сценариев инициализации, применяемых для запуска, останова и повторного запуска сервисов. В прошлом они хранились в разных местах в каталоге /etc, часто в /etc/init.d или в /etc/rc.d/init.d. Подобное разнообразие часто было причиной путаницы, поскольку пользователи, менявшие дистрибутивы, не могли найти сценарии инициализации в привычных местах, и установка программ завершалась аварийно при попытке выполнить сценарий инициализации из неверного каталога.

Стандарт LSB 3.1 определяет каталог /etc/init.d, как место хранения сценариев инициализации, но при этом разрешает этому каталогу быть ссылкой на другое место в системе.

У каждого сценария в каталоге /etc/init.d есть имя, связанное с предоставляемым им сервисом. Поскольку все сервисы ОС Linux должны совместно использовать одно пространство имен, важно, чтобы эти имена были уникальны. Например, жизнь будет несладкой, если сервисы MySQL и PostgreSQL решат назвать свои сценарии "database". Для устранения такого конфликта существует еще один набор стандартов. Это стандарт Assigned Names And Numbers Authority (LANANА, орган назначения имен и номеров в Linux), который можно найти на Web-сайте http://www.lanana.org/. К счастью, вам понадобится знать очень немногое об этом стандарте, за исключением того, что в нем хранится список зарегистрированных имен сценариев и пакетов, облегчающий жизнь пользователям систем Linux.

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

Таблица 18.2

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

status

Последний стандарт, который мы собираемся, рассмотреть в этой главе, — Filesystem Hierarchy Standard (FHS, стандарт иерархии файловой системы). Его можно найти по адресу http://www.pathname.com/fhs/.

Назначение этого стандарта — определение типовых мест хранения в файловой системе Linux для того, чтобы как разработчики, так и пользователи могли делать обоснованные предположения относительно местонахождения тех или иных файлов. Многолетние пользователи UNIX-подобных операционных систем долгое время жаловались на трудноуловимые различия в схемах расположения файловых систем, и стандарт FHS предлагает дистрибутивам Linux способ избежать повторения этого прерывистого пути.

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

□ файлы и каталоги, уникальные для конкретной работающей системы Linux, такие как сценарии запуска и файлы конфигурации;

□ файлы и каталоги, предназначенные только для чтения и, возможно, совместно используемые несколькими работающими системами Linux, например исполняемые файлы приложений;

□ каталоги, предназначенные для чтения/записи, но, возможно, совместно используемые работающими системами Linux или другими операционными системами, например исходные каталоги пользователей.

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

В стандарте FHS определена структура верхнего уровня, имеющая ряд обязательных подкаталогов и несколько необязательных каталогов; основные из них приведены в табл. 18.3.

Таблица 18.3

Кроме того, могут существовать и другие каталоги, начинающиеся с lib, хотя это и не распространено. Как правило, вы также будете встречать каталог /lost+found (для восстановления файловой системы с помощью программы fsck) и каталог /proc, представляющий собой псевдофайловую систему, обеспечивающую отображение работающей системы. Текущая версия стандарта FHS усиленно поддерживает файловую систему /proc, но ее присутствие не обязательно. Подробности, касающиеся системы /proc, в основном выходят за рамки тем, обсуждаемых в этой книге, хотя мы и привели ее краткий обзор в главе 3.

Далее познакомимся вкратце с назначением каждого из стандартных подкаталогов корневого каталога /.

□ /bin — содержит двоичные файлы, которые могут использовать как пользователь root, так и обычные пользователи и которые важны для функционирования в однопользовательском режиме, когда некоторые другие структуры каталогов могут не монтироваться. Например, обычно здесь можно найти команды ядра

cat

ls

sh

□ /boot — применяется для файлов, требуемых во время загрузки системы Linux. Часто этот каталог очень мал, менее 10 Мбайт, и часто это отдельный раздел. Это очень удобно в системах на базе PC, в которых есть ограничения BIOS для активного раздела, который должен находиться в первых 2 или 4 Гбайт диска. Имея этот каталог в виде отдельного раздела, вы будете обладать большей гибкостью при размещении остальных разделов диска.

□ /dev — содержит специальные файлы устройств, отображаемые на аппаратные устройства. Например, /dev/had будет отображаться на первый диск IDE.

□ /etc — содержит файлы конфигурации. По традиции здесь можно найти и некоторые двоичные файлы, но это уже не соответствует действительности для большинства современных систем Linux. Самый известный файл в каталоге /etc — это, вероятно, файл passwd, содержащий информацию о пользователях. Другие полезные файлы — fstab с перечнем вариантов монтирования; hosts со списком отображений IP-адресов в имена компьютеров, и каталог httpd, содержащий конфигурацию для сервера Apache.

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

□ /lib — содержит важные совместно используемые библиотеки и модули ядра, особенно те, которые потребуются во время загрузки системы в однопользовательском режиме.

□ /media — задуман как каталог верхнего уровня для хранения каталогов-точек монтирования для съемных носителей. Цель — иметь возможность удалять ненужные каталоги верхнего уровня, такие как /cdrom и /floppy.

□ /mnt — просто удобное место для монтирования на время дополнительных файловых систем. По сложившейся традиции некоторые дистрибутивы добавляли в  каталог /mnt подкаталоги для разных устройств, таких как /cdrom и /floppy, но в настоящее время предпочтительнее размещать их в каталоге /media, вернув /mnt его первоначальное назначение — единое место размещения верхнего уровня для временного монтирования (single top-level temporary mount location).

□ /opt — каталог для поставщиков программного обеспечения, используемый для вставки программных приложений, добавляемых к базовому дистрибутиву. Дистрибутивы не должны пользоваться им для хранения программного обеспечения, которое поставляется как часть стандартного дистрибутива, его следует оставлять для использования сторонними поставщиками. Обычно поставщики будут создавать подкаталоги со своими именами и в них последующие каталоги, такие как /bin и /lib, для файлов, относящихся к их приложению.

Примечание

По принятому соглашению многие пакеты Open Source Linux используют каталог /usr/local для инсталляции.

□ /root — это каталог для файлов, используемых пользователем root. Он не входит в ветвь каталога /home в дереве каталогов, поскольку может не монтироваться в однопользовательском режиме.

□ /sbin — применяется для команд, обычно используемых только системным администратором и требующихся во время загрузки системы в однопользовательском режиме. Здесь обитают команды

fsck

halt

swapon

□ /srv — предназначен для размещения данных местного назначения в режиме "только для чтения", но в настоящее время он широко не используется.

□ /tmp — применяется для временных файлов. Обычно, но не всегда, очищается при загрузке системы.

□ /usr — довольно сложная вспомогательная файловая система, как правило, содержащая все команды системного типа и библиотеки, не требуемые при загрузке системы или в однопользовательском режиме. В каталоге много подкаталогов, таких как /bin, /lib, /X11R6 и /local.

Примечание

Когда только появились системы UNIX и Linux, каталог /usr также имел подкаталоги для регистраций, буферизации электронной почты и т.п. Теперь все эти подкаталоги удалены из каталога usr и помещены в каталог var. Преимущество такого подхода в том, что теперь /usr может быть монтируемой файловой системой, ее могут совместно использовать другие системы в сети, и он стал менее чувствителен к повреждениям системы, которые останавливают ее неуправляемым образом, например из-за отказа электропитания.

□ /var — содержит часто меняющиеся данные, такие как файлы буферов печати, файлы регистраций приложений и каталоги буферизации электронной почты.

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

Вы хотите локализовать ваше приложение, так чтобы оно работало на разных языках и с разными региональными установками? Даже если вы ограничены английским языком, остается выбор валюты, разделителей в числах, форматов дат и множество других требующих внимания параметров. Как вы догадываетесь, есть специалисты, работающие над такими стандартами; увидеть их работу можно на Web-сайте http://www.openi18n.org/.

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

autoconf

automake

./configure; make

Польза от применения этих средств выходит за рамки обсуждаемых в данной книге тем, но вы можете найти дополнительную информацию о них на Web-страницах проекта GNU http://www.gnu.org/software/autoconf/ и http://www.gnu.org/software/automake.

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