Текст книги "Основы программирования в Linux"

Автор книги: Нейл Мэтью

Соавторы: Ричард Стоунс
сообщить о нарушении

Текущая страница: 66 (всего у книги 67 страниц)

Опции gcc

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

У gcc есть огромный набор опций, и здесь мы рассмотрим лишь те из них, которые считаем наиболее важными. Полный перечень опций можно найти на страницах интерактивного справочного руководства gcc. Мы также кратко обсудим некоторые опции директивы #define, которые можно применять; обычно их следует задавать в вашем исходном программном коде перед любыми строками с директивой #include или определять в командной строке gcc. Вас может удивить такое обилие опций для выбора применяемого стандарта вместо простого флага, заставляющего использовать современный стандарт. Причина заключается в том, что много более старых программ полагается на исторически сложившееся поведение компилятора и потребовалась бы значительная работа по их обновлению в соответствии с последними стандартами. Редко, если вообще когда-нибудь, вам захочется обновить компилятор для того, чтобы он начал прерывать работающий программный код. По мере изменения стандартов важно иметь возможность работать вопреки определенному стандарту, даже если это и не самая свежая версия стандарта.

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

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

Опции компилятора для отслеживания стандартов

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

□ -ansi – это самая важная опция, касающаяся стандартов и заставляющая компилятор действовать в соответствии со стандартом языка ISO C90. Она отключает некоторые расширения gcc, не совместимые со стандартом, отключает в программах на языке С комментарии в стиле С++ (//) и включает обработку триграфов (трехсимвольных последовательностей) ANSI. Кроме того, она содержит макрос __STRICT_ANSI__, который отключает некоторые расширения в заголовочных файлах, не совместимые со стандартом. В последующих версиях компилятора принятый стандарт может измениться.

□ -std= – эта опция обеспечивает более тонкий контроль используемого стандарта, предоставляя параметр, точно задающий требуемый стандарт. Далее приведены основные возможные варианты:

 • с89 – поддерживать стандарт C89;

 • iso9899:1999– поддерживать последнюю версию стандарта ISO, C90;

 • gnu89 – поддерживать стандарт C89, но разрешить некоторые расширения GNU и некоторые функциональные возможности C99. В версии 4.2 gcc этот вариант применяется по умолчанию.

Опции для отслеживания стандарта в директивах define

Существуют константы (#defines), которые могут задаваться опциями в командной строке или виде определений в исходном тексте программы. Мы, как правило, считаем, что для них используется командная строка компилятора.

□ __STRICT_ANSI__ – заставляет применять стандарт С ISO. Определяется, когда в командной строке компилятора задана опция -ansi.

□ _POSIX_C_SOURCE=2 – активизирует функциональные возможности, определенные стандартами IEEE Std 1003.1 и 1003.2. Мы вернемся к этим стандартам чуть позже в этой главе.

□ _BSD_SOURCE – включает функциональные возможности систем BSD. Если они конфликтуют с определениями POSIX, определения BSD обладают более высоким приоритетом.

□ _GNU_SOURCE – допускает широкий диапазон свойств и функций, включая расширения GNU. Если эти определения конфликтуют с определениями POSIX, у последних более высокий приоритет.

Опции компилятора для вывода предупреждений

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

□ -pedantic – эта наиболее мощная опция проверки чистоты, программного кода на языке С. Помимо включения опции проверки на соответствие стандарту С, она отключает некоторые традиционные конструкции языка С, запрещенные стандартом, и делает недопустимыми все расширения GNU по отношению к стандарту. Эту опцию следует применять, чтобы добиться максимальной переносимости вашего кода на С. Недостаток ее в том, что компилятор сильно озабочен чистотой вашего программного кода, и порой приходится поломать голову для того, чтобы разделаться с несколькими оставшимися предупреждениями.

□ -Wformat – проверяет корректность типов аргументов функций семейства printf.

□ -Wparentheses – проверяет наличие скобок, даже там, где они не нужны. Эта опция очень полезна для проверки того, что сложные структуры инициализированы так, как задумано.

□ -Wswitch-default – проверяет наличие варианта default в операторах switch, что обычно считается хорошим стилем программирования.

□ -Wunused – проверяет разнообразные случаи, например, статические функции объявленные, но не описанные, неиспользуемые параметры, отброшенные результаты.

□ -Wall – включает большинство типов предупреждений gcc, в том числе все предыдущие опции -W (не охватывается только -pedantic). С ее помощью легко добиться чистоты программного кода.

Примечание

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

Интерфейсы и Linux Standards Base

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

Определяющий документ в этой области для ОС 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).

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

Стандартные библиотеки LSB

Документация 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 к библиотекам

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

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

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

Пользователи и группы LSB

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

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

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

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

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

Инициализация системы LSB

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

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

Таблица 18.1

0	Halt. Применяется как логическое состояние, к которому следует перейти при остановке системы
1	Однопользовательский режим. Каталоги, отличающиеся от / (корневой), могут не монтироваться, и сетевой поддержки не будет. Обычно применяется для обслуживания системы
2	Многопользовательский режим, но без сетевой поддержки
3	Обычный многопользовательский режим с сетевой поддержкой, использующий экран регистрации в текстовом режиме
4	Зарезервирован
5	Обычный многопользовательский режим с сетевой поддержкой, использующий экран регистрации в графическом режиме
6	Псевдоуровень, применяемый для перезагрузки

Стандарт 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

start	Запускает (или перезапускает) сервис
stop	Останавливает сервис
restart	Перезапускает сервис; обычно реализован как простой останов сервиса, за которым следует запуск этого сервиса
reload	Переустанавливает сервис, повторно загружая параметры без реальной остановки сервиса. Этот вариант поддерживают не все сервисы, поэтому данный параметр может быть недоступен в некоторых сценариях, а если доступен, то не имеет эффекта
force-reload	Пытается вызвать переустановку, если сервис ее поддерживает, если нет – выполняет перезапуск сервиса
status	Выводит текстовое сообщение о состоянии сервиса и возвращает код состояния, который может применяться для определения состояния сервиса

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

Стандарт устройства файловой системы

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

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

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

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

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

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

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

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

Таблица 18.3

/bin	Да	Важные системные двоичные файлы
/boot	Да	Файлы, необходимые для загрузки системы
/dev	Да	Устройства
/etc	Да	Системные файлы конфигурации
/home	Нет	Каталоги для файлов пользователей
/lib	Да	Стандартные библиотеки
/media	Да	Место для съемных монтируемых носителей с отдельными подкаталогами для каждого типа носителей, поддерживаемого системой
/mnt	Да	Удобная точка для временно монтируемых устройств, таких как CD-ROM и накопители флэш-памяти
/opt	Да	Дополнительное прикладное программное обеспечение
/root	Нет	Файлы пользователя root
/sbin	Да	Важные системные двоичные файлы, которые необходимы в процессе запуска системы
/srv	Да	Предназначенные только для чтения данные для сервисов, предоставляемых данной системой
/tmp	Да	Временные файлы
/usr	Да	Вспомогательная иерархия. Традиционно файлы пользователей также хранятся здесь, но в наши дни это считается дурным стилем и обычным пользователем не следует предоставлять право записи в этот каталог
/var	Да	Переменные данные, например файлы регистрации

Кроме того, могут существовать и другие каталоги, начинающиеся с 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 – содержит часто меняющиеся данные, такие как файлы буферов печати, файлы регистраций приложений и каталоги буферизации электронной почты.