Одной из движущих целей первоначального проекта Unix была простота. Простые понятия легко изучать и использовать. Когда понятия переведены в простые API, легко проектировать, писать и отлаживать простые программы. Вдобавок, простой код часто занимает меньше места и он более эффективен, чем более усложненные проекты.

Поиск простоты направлялся двумя факторами. С технической точки зрения, первоначальные мини-компьютеры PDP-11, на которых разрабатывалась Unix, имели маленькое адресное пространство: 64 килобайта на меньших системах, 64 Кб кода и 64 Кб данных на больших. Эти ограничения относились не только к обычным программам (так называемому коду уровня пользователя), но и к самой операционной системе (коду уровня ядра). Поэтому не только «Маленький — значит красивый» в эстетическом смысле, но «Маленький — значит красивый», потому что не было другого выбора!

Вторым фактором была отрицательная реакция на современные коммерческие операционные системы, которые были без надобности усложнены, со сложными командными языками, множеством разновидностей файлового ввода-вывода и слабой общностью или гармонией. (Стив Джонсон однажды заметил: «Использование TSO подобно пинанию мертвого кита на побережье». TSO — это как раз одна из только что описанных бестолковых систем с разделением времени «для мэйнфреймов.)

1.1.1. Файлы и права доступа

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

Если у вас есть файл, вы можете сделать с данными в файле три вещи: прочитать, записать или исполнить их.

Unix разрабатывался для мини-компьютеров с разделением времени; это предполагает наличие с самого начала многопользовательского окружения. Раз есть множество пользователей, должно быть возможным указание прав доступа к файлам: возможно, пользователь jane является начальником пользователя fred, и jane не хочет, чтобы fred прочел последние результаты аттестации.

В целях создания прав доступа пользователи подразделяются на три различные категории: владелец файла; группа пользователей, связанная с данным файлом (вскоре будет пояснено); и остальные пользователи. Для каждой из этих категорий каждый файл имеет отдельные, связанные с этим файлом, биты прав доступа, разрешающие чтение, запись и исполнение. Эти разрешения отображаются в первом поле вывода команды 'ls -l':

$ ls -l progex.texi

-rw-r--r-- 1 arnold devel 5614 Feb 24 18:02 progex.texi

Здесь arnold и devel являются соответственно владельцем и группой файла progex.texi, a -rw-r--r-- является строкой типа файла и прав доступа. Для обычного файла первым символом будет дефис, для каталогов - d, а для других видов файлов - небольшой набор других символов, которые пока не имеют значения. Каждая последующая тройка символов представляют права на чтение, запись и исполнение для владельца, группы и «остальных» соответственно.

В данном примере файл progex.texi может читать и записывать владелец файла, а группа и остальные пользователи могут только читать. Дефисы означают отсутствие разрешений, поэтому этот файл никто не может исполнить, а группа и остальные пользователи не могут в него записывать.

Владелец и группа файла хранятся в виде числовых значений, известных как идентификатор пользователя (user ID — UID) и идентификатор группы (group ID — GID); стандартные библиотечные функции, которые мы рассмотрим далее в книге, позволяют напечатать эти значения в виде читаемых имен.

Владелец файла может изменить разрешения, используя команду chmod (change mode — изменить режим). (Права доступа к файлу, по существу, иногда называют «режимом файла».) Группу файла можно изменить с помощью команд chgrp (change group — изменить группу) и chown (change owner — сменить владельца).

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

Когда система проверяет доступ к файлу (обычно при открытии файла), если UID процесса совпадает с UID файла, используются права доступа владельца файла. Если эти права доступа запрещают операцию (скажем, попытка записи в файл с доступом -r--rw-rw-), операция завершается неудачей; Unix и Linux не продолжают проверку прав доступа для группы и других пользователей. Это верно также, если UID различаются, но совпадают GID; если права доступа группы запрещают операцию, она завершается неудачей.

Unix и Linux поддерживают понятие суперпользователя (superuser): это пользователь с особыми привилегиями. Этот пользователь известен как root и имеет UID, равный 0. root позволено делать все; никаких проверок, все двери открыты, все ящики отперты. (Это может иметь важные последствия для безопасности, которых мы будем касаться по всей книге, но не будем освещать исчерпывающе.) Поэтому, даже если файл имеет режим ----------, root все равно может читать файл и записывать в него. (Исключением является то, что файл нельзя исполнить. Но поскольку root может добавить право на исполнение, это ограничение ничего не предотвращает.)

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

1.1.2. Каталоги и имена файлов

Раз у вас есть файл, нужно где-то его хранить. В этом назначение каталога (известного в системах Windows или Apple Macintosh под названием «папка»). Каталог является особой разновидностью файла, связывающего имена файлов с метаданными, известными как узлы (inodes). Каталоги являются особыми, поскольку их может обновлять лишь операционная система путем описанных в главе 4, «Файлы и файловый ввод-вывод», системных вызовов. Они особые также потому, что операционная система предписывает формат элементов каталога.

Имена файлов могут содержать любой 8-битный байт, за исключением символа '/' (прямой косой черты) и ASCII символа NUL, все биты которого содержат 0. Ранние Unix- системы ограничивали имена 14 байтами; современные системы допускают отдельные имена файлов вплоть до 255 байтов.

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

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

ЗАМЕЧАНИЕ . Если у вас есть разрешение на запись в каталог, вы можете удалять файлы из этого каталога, даже если они не принадлежат вам! При интерактивной работе команда rm отмечает это, запрашивая в таком случае подтверждение

Каталог /tmp имеет разрешение на запись для каждого, но ваши файлы в /tmp находятся вполне в безопасности, поскольку /tmp обычно имеет установленный так называемый «липкий» (sticky) бит:

$ ls -ld /trap

drwxrwxrwt 11 root root 4096 May 15 17:11 /tmp

Обратите внимание, что t находится в последней позиции первого поля. В большинстве каталогов в этом месте стоит x. При установленном «липком» бите ваши файлы можете удалять лишь вы, как владелец файла, или root . (Более детально это обсуждается в разделе 11.2 5, «Каталоги и липкий бит».)

1.1.3. Исполняемые файлы

Помните, мы говорили, что операционная система на накладывает структуру на файлы? Мы уже видели, что это было невинной ложью относительно каталогов. Это же относится к двоичным исполняемым файлам. Чтобы запустить программу, ядро должно знать, какая часть файла представляет инструкции (код), а какая — данные. Это ведет к понятию формата объектного файла, которое определяет, как эти данные располагаются внутри файла на диске.

Хотя ядро запустит лишь файлы, имеющие соответствующий формат, создание таких файлов задача утилит режима пользователя. Компилятор с языка программирования (такого как Ada, Fortran, С или С++) создает объектные файлы, а затем компоновщик или загрузчик (обычно с именем ld) связывает объектные файлы с библиотечными функциями для окончательного создания исполняемого файла. Обратите внимание, что даже если все нужные биты в файле размешены в нужных местах, ядро не запустит его, если не установлен соответствующий бит, разрешающий исполнение (или хотя бы один исполняющий бит для root).

Поскольку компилятор, ассемблер и загрузчик являются инструментами режима пользователя, изменить со временем по мере необходимости форматы объектных файлов (сравнительно) просто; надо только «научить» ядро новому формату, и он может быть использован. Часть ядра, загружающая исполняемые файлы, относительно невелика, и это не является невозможной задачей. Поэтому форматы файлов Unix развиваются с течением времени. Первоначальный формат был известен как a.out (Assembler OUTput — вывод сборщика). Следующий формат, до сих пор использующийся в некоторых коммерческих системах, известен как COFF (Common Object File Format — общий формат объектных файлов), а современный, наиболее широко использующийся формат — ELF (Extensible Linking Format — открытый формат компоновки). Современные системы GNU/Linux используют ELF.

Ядро распознает, что исполняемый файл содержит двоичный объектный код, проверяя первые несколько байтов файла на предмет совпадения со специальными магическими числами. Это последовательности двух или четырех байтов, которые ядро распознает в качестве специальных. Для обратной совместимости современные Unix-системы распознают несколько форматов. Файлы ELF начинаются с четырех символов «\177ELF».

Помимо двоичных исполняемых файлов, ядро поддерживает также исполняемые сценарии (скрипты). Такой файл также начинается с магического числа: в этом случае, это два обычных символа # ! . Сценарий является программой, исполняемой интерпретатором, таким, как командный процессор, awk, Perl, Python или Tcl. Строка, начинающаяся с #!, предоставляет полный путь к интерпретатору и один необязательный аргумент:

#! /bin/awk -f

BEGIN {print "hello, world"}

Предположим, указанное содержимое располагается в файле hello.awk и этот файл исполняемый. Когда вы набираете 'hello.awk', ядро запускает программу, как если бы вы напечатали '/bin/awk -f hello.awk'. Любые дополнительные аргументы командной строки также передаются программе. В этом случае, awk запускает программу и отображает общеизвестное сообщение hello, world.

Механизм с использованием #! является элегантным способом скрыть различие между двоичными исполняемыми файлами и сценариями. Если hello.awk переименовать просто в hello, пользователь, набирающий 'hello', не сможет сказать (и, конечно, не должен знать), что hello не является двоичной исполняемой программой.

1.1.4. Устройства

Одним из самых замечательных новшеств Unix было объединение файлового ввода- вывода и ввода-вывода от устройств. Устройства выглядят в файловой системе как файлы, для доступа к ним используются обычные права доступа, а для их открытия, чтения, записи и закрытия используются те же самые системные вызовы ввода-вывода. Вся «магия», заставляющая устройства выглядеть подобно файлам, скрыта в ядре. Это просто другой аспект движущего принципа простоты в действии, мы можем выразить это как никаких частных случаев для кода пользователя.

В повседневной практике, в частности, на уровне оболочки, часто появляются два устройства: /dev/null и /dev/tty.

/dev/null является «битоприемником». Все данные, посылаемые /dev/null, уничтожаются операционной системой, а все попытки прочесть отсюда немедленно возвращают конец файла (EOF).

/dev/tty является текущим управляющим терминалом процесса — тем, который он слушает, когда пользователь набирает символ прерывания (обычно CTRL-C) или выполняет управление заданием (CTRL-Z).

Системы GNU/Linux и многие современные системы Unix предоставляют устройства /dev/stdin, /dev/stdout и /dev/stderr, которые дают возможность указать открытые файлы, которые каждый процесс наследует при своем запуске.

Другие устройства представляют реальное оборудование, такое, как ленточные и дисковые приводы, приводы CD-ROM и последовательные порты. Имеются также программные устройства, такие, как псевдотерминалы, которые используются для сетевых входов в систему и систем управления окнами, /dev/console представляет системную консоль, особое аппаратное устройство мини-компьютеров. В современных компьютерах /dev/console представлен экраном и клавиатурой, но это может быть также и последовательный порт

К сожалению, соглашения по именованию устройств не стандартизированы, и каждая операционная система использует для лент, дисков и т.п. собственные имена. (К счастью, это не представляет проблемы для того, что мы рассматриваем в данной книге.) Устройства имеют в выводе 'ls -l' в качестве первого символа b или с.

$ ls -l /dev/tty /dev/hda

brw-rw-rw- 1 root disk 3, 0 Aug 31 02:31 /dev/hda

crw-rw-rw- 1 root root 5, 0 Feb 26 08:44 /dev/tty

Начальная 'b' представляет блочные устройства, а 'c' представляет символьные устройства. Файлы устройств обсуждаются далее в разделе 5.4, «Получение информации о файлах».

Процесс является работающей программой. Процесс имеет следующие атрибуты:

уникальный идентификатор процесса (PID);

• родительский процесс (с соответствующим идентификатором, PPID);

• идентификаторы прав доступа (UID, GID, набор групп и т.д.);

• отдельное от всех других процессов адресное пространство;

• программа, работающая в этом адресном пространстве;

• текущий рабочий каталог ('.');

• текущий корневой каталог (/; его изменение является продвинутой темой);

• набор открытых файлов, каталогов, или и того, и другого;

• маска запретов доступа, использующаяся при создании новых файлов;

• набор строк, представляющих окружение;

• приоритеты распределения времени процессора (продвинутая тема);

• установки для размещения сигналов (signal disposition) (продвинутая тема); управляющий терминал (тоже продвинутая тема).

Когда функция main() начинает исполнение, все эти вещи уже помещены в работающей программе на свои места. Для запроса и изменения каждого из этих вышеназванных элементов доступны системные вызовы; их освещение является целью данной книги.

Новые процессы всегда создаются существующими процессами. Существующий процесс называется родительским, а новый процесс — порожденным. При загрузке ядро вручную создает первый, изначальный процесс, который запускает программу /sbin/init; идентификатор этого процесса равен 1, он осуществляет несколько административных функций. Все остальные процессы являются потомками init. (Родительским процессом init является ядро, часто обозначаемое в списках как процесс с ID 0.)

Отношение порожденный-родительский является отношением один к одному; у каждого процесса есть только один родитель, поэтому легко выяснить PID родителя. Отношение родительский-порожденный является отношением один ко многим; каждый данный процесс может создать потенциально неограниченное число порожденных. Поэтому для процесса нет простого способа выяснить все PID своих потомков. (Во всяком случае, на практике это не требуется.) Родительский процесс можно настроить так, чтобы он получал уведомление при завершении порожденного процесса, он может также явным образом ожидать наступления такого события.

Адресное пространство (память) каждого процесса отделена от адресного пространства всех остальных процессов. Если два процесса не договорились явным образом разделять память, один процесс не может повлиять на адресное пространство другого. Это важно; это обеспечивает базовый уровень безопасности и надежности системы. (В целях эффективности, система разделяет исполняемый код одной программы с правом доступа только для чтения между всеми процессами, запустившими эту программу. Это прозрачно для пользователя и запущенной программы.)

Текущий рабочий каталог — это каталог, относительно которого отсчитываются относительные пути файлов (те, которые не начинаются с '/'). Это каталог, в котором вы находитесь, когда набираете команду оболочки 'cd someplace '.

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

Окружение представляет собой набор строк, каждая в виде 'имя=значение'. Для запроса и установки значений переменных окружения имеются специальные функции, а порожденные процессы наследуют окружение своих родителей. Типичными переменными окружения оболочки являются PATH и НОМЕ. Многие программы для управления своим поведением полагаются на наличие и значения определенных переменных окружения.

Важно понять, что один процесс в течение своего существования может исполнить множество программ. Все устанавливаемые системой атрибуты (текущий каталог, открытые файлы, PID и т.д.) остаются теми же самыми, если только они не изменены явным образом. Отделение «запуска нового процесса» от «выбора программы для запуска» является ключевым нововведением Unix. Это упрощает многие операции. Другие операционные системы, которые объединяют эти две операции, являются менее общими и их сложнее использовать.

1.2.1. Каналы: сцепление процессов

Без сомнения, вам приходилось использовать конструкцию ('|') оболочки для соединения двух или более запущенных программ. Канал действует подобно файлу: один процесс записывает в него, используя обычную операцию записи, а другой процесс считывает из него с помощью операции чтения. Процессы (обычно) не знают, что их ввод/вывод является каналом, а не обычным файлом.

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

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

Что делает программу GNU программой GNU? Что делает программное обеспечение GNU «лучше» по сравнению с другим (платным или бесплатным) программным обеспечением? Наиболее очевидной разницей является общедоступная лицензия (General Public License — GPL), которая описывает условия распространения для программного обеспечения GNU. Но это обычно не причина, чтобы вы могли услышать, как люди говорят: «Дайте GNU-версию xyz, она намного лучше». Программное обеспечение GNU в общем более устойчиво, имеет лучшую производительность, чем в стандартных версиях Unix. В данном разделе мы рассмотрим некоторые причины этого явления, а также рассмотрим документ, описывающий принципы проектирования программного обеспечения GNU.

«Стандарты кодирования GNU» (GNU Coding Standards) описывают создание программного обеспечения для проекта GNU. Они охватывает ряд тем. Вы можете найти GNU Coding Standards по адресу http://www.gnu.org/prep/standards.html. Смотрите в онлайн-версии ссылки на исходные файлы в других форматах.

В данном разделе мы описываем лишь те части GNU Coding Standards, которые относятся к проектированию и реализации программ.

1.4.1. Проектирование программ

Глава 3 GNU Coding Standards содержит общие советы относительно проектирования программ. Четырьмя главными проблемами являются совместимость (со стандартами и с Unix), язык, использование нестандартных возможностей других программ (одним словом, «ничего»), и смысл «переносимости».

Важной целью является совместимость со стандартом С и POSIX, а также, в меньшей степени, с Berkley Unix. Но она не преобладает. Общей идеей является предоставление всех необходимых возможностей через аргументы командной строки для предоставления точного режима ISO или POSIX.

Предпочтительным языком для написания программного обеспечения GNU является С, поскольку это наиболее доступный язык. В мире Unix стандарт С теперь обычен, но если для вас не представляет труда поддержка оригинального С, вы должны сделать это. Хотя стандарты кодирования отдают предпочтение С перед С++, C++ теперь тоже вполне обычен. Примером широко используемого пакета GNU, написанного на С++, является groff (GNU troff). Наш опыт говорит, что с GCC, поддерживающим С++, установка groff не представляет сложности.

Стандарты утверждают, что переносимость является чем-то вроде отвлекающего маневра. Утилиты GNU ясно нацелены на работу с ядром GNU и с библиотекой GNU С. Но поскольку ядро еще не завершено, и пользователи используют инструменты GNU на не-GNU системах, переносимость желательна, но не является первостепенной задачей. Стандарт рекомендует для достижения переносимости между различными системами Unix использовать Autoconf.

1.4.2. Поведение программы

Глава 4 GNU Coding Standards предоставляет общие советы относительно поведения программы. Ниже мы вернемся к одному из ее разделов для более подробного рассмотрения. Глава фокусируется на строении программы, форматировании сообщений об ошибках, написании библиотек (делая их рентабельными) и стандартах для интерфейса командной строки.

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

Утилиты GNU должны использовать для обработки командной строки функцию getopt_long(). Эта функция предусматривает разбор аргументов командной строки как для опций в стиле традиционного Unix ('gawk -F:...'), так и для длинных опций в стиле GNU ('gawk --field-separator=:...'). Все программы должны предусматривать опции --help и --version, а когда в одной программе используется длинное имя, оно таким же образом должно использоваться и в другой программе GNU. Для этой цели есть довольно полный список длинных опций, используемых современными GNU-программами.

В качестве простого, но очевидного примера, --verbose пишется точно таким же способом во всех GNU-программах. Сравните это с -v, -V, -d и т.д. во многих других программах Unix. Большая часть главы 2, «Аргументы, опции и окружение», с. 23, посвящена механике разбора аргументов и опций.

1.4.3. Программирование на С

Наиболее привлекательной частью GNU Coding Standards является глава 5, которая описывает написание кода на С, освещая такие темы, как форматирование кода, правильное использование комментариев, чистое использование С, именование ваших функций и переменных, а также объявление или не объявление стандартных системных функций, которые вы хотите использовать.

Форматирование кода является религиозной проблемой; у многих людей разные стили, которые они предпочитают. Лично нам не нравится стиль FSF, и если вы взглянете на gawk, который мы поддерживаем, вы увидите, что он форматирован в стандартном стиле K&R (стиль расположения кода, использованный в обоих изданиях книги Кернигана и Ричи). Но это единственное отклонение в gawk от этой части стандартов кодирования.

Тем не менее, хотя нам и не нравится стиль FSF, мы чувствуем, что при модификации некоторых других программ, придерживание уже использованного стиля кода является исключительно важным. Последовательность в стиле кода более важна, чем сам стиль, который вы выбираете. GNU Coding Standards дает такой же совет. (Иногда невозможно обнаружить последовательный стиль кода, в этом случае программа, возможно, испорчена использованием indent от GNU или cb от Unix.)

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

1.4.4. Вещи, которые делают программы GNU лучше

Теперь мы рассмотрим раздел, озаглавленный «Написание надежных программ», в главе 4 «Поведение программ для всех программ». Этот раздел описывает принципы проектирования программного обеспечения, которые делают программы GNU лучше их двойников в Unix Мы процитируем выбранные части главы, с несколькими примерами случаев, в которых эти принципы окупились.

Избегайте произвольных ограничений длины или числа любой структуры данных, включая имена файлов, строки, файлы и символы, выделяя все структуры данных динамически. В большинстве инструментов Unix «длинные строки молча срезаются». Это неприемлемо в инструменте GNU.

Это правило, возможно, единственное наиболее важное в проектировании программного обеспечения GNU — никаких произвольных ограничений. Все инструменты GNU должны быть способны обрабатывать произвольные объемы данных.

Хотя это требование, возможно, усложняет работу программиста, оно облегчает жизнь пользователю. С одной стороны, у нас есть пользователь gawk, регулярно запускающий программу awk для более чем 650 000 файлов (нет, это не опечатка) для сбора статистики, gawk заняла бы более 192 мегабайтов пространства данных, и программа работала бы в течение 7 часов. Он не смог бы запустить эту программу, используя другую реализацию awk.

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

Также хорошо известно, что Emacs может редактировать любые произвольные файлы, включая файлы, содержащие двоичные данные!

По возможности, программы должны обрабатывать должным образом последовательности байтов, представляющих многобайтные символы, используя такие кодировки, как UTF-8 и другие. [23] Каждый системный вызов проверяйте на предмет возвращенной ошибки, если вы не хотите игнорировать ошибки. Включите текст системной ошибки (от perror или эквивалентной функции) в каждое сообщение об ошибке, возникшей при неудачном системном вызове, также, как и имя файла, если он есть, и имя утилиты. Простого «невозможно открыть foo.с» или «ошибка запуска» недостаточно.

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

Наконец, мы цитируем главу 1 GNU Coding Standards, которая обсуждает, как написать вашу программу способом, отличным от того, каким написаны программы Unix.

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

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

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

Великолепным примером того, какое отличие можно сделать в алгоритме, является GNU diff. Одним из первых ранних воплощений нашей системы было AT&T 3B1, система с процессором МС68010, огромными двумя мегабайтами памяти и 80 мегабайтами на диске. Мы проделали (и делаем) кучу исправлений в руководстве для gawk, файле длиной почти 28 000 строк (хотя в то время он был лишь в диапазоне 10 000 строк). Обычно мы частенько использовали 'diff -с', чтобы посмотреть на сделанные нами изменения. На этой медленной системе переключение на GNU diff показало ошеломительную разницу во времени появления контекста diff. Разница почти всецело благодаря лучшему алгоритму, который использует GNU diff.

В последнем параграфе упоминается идея структурирования программы как независимо используемой библиотеки, с оболочкой командной строки или другим окружающим се интерфейсом. Примером этого является GDB, отладчик GNU, который реализован в виде инструмента с интерфейсом командной строки поверх отладочной библиотеки. (Разделение основных возможностей GDB от интерфейса командной строки является продолжающимся проектом). Эта реализация дает возможность создать поверх отладочных функциональных возможностей графический интерфейс отладчика.

1.4.5. Заключительные соображения по поводу «GNU Coding Standards»

GNU Coding Standards является стоящим для прочтения документом, если вы хотите разрабатывать новое программное обеспечение GNU, обмениваться существующими программами GNU или просто научиться программировать лучше. Принципы и методики, которые она поддерживает — вот что делает программное обеспечение GNU предпочитаемым выбором в сообществе Unix.

У слова аргументы есть два значения. Более техническим определением является «все 'слова' в командной строке». Например:

$ ls main.с opts.с process.с

Здесь пользователь напечатал четыре «слова». Все четыре слова сделаны доступными программе в качестве ее аргументов.

Второе определение более неформальное: аргументами являются все слова командной строки, за исключением имени команды. По умолчанию, оболочки Unix отделяют аргументы друг от друга разделителями (пробелами или символами TAB). Кавычки позволяют включать в аргументы разделитель:

$ echo here are lots of spaces

here are lots of spaces /* Оболочка «съедает» пробелы */

$ echo "here are lots of spaces"

here are lots of spaces /* Пробелы остались */

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

Аргументы можно подразделить далее на опции и операнды. В предыдущих двух примерах все аргументы были операндами: файлы для ls и простой текст для echo.

Опции являются специальными аргументами, которые каждая программа интерпретирует. Опции изменяют поведение программы или предоставляют программе информацию. По старому соглашению, которого (почти) всегда придерживаются, опции начинаются с черточки (т.е. дефиса, значка минус), и состоят из единственной буквы. Аргументы опции являются информацией, необходимой для опции, в отличие от обычных аргументов-операндов. Например, опция -f программы fgrep означает «использовать содержимое следующего файла в качестве списка строк для поиска». См. рис 2.1.

Рис. 2.1. Компоненты командной строки

Таким образом, patfile является не файлом данных для поиска, а предназначен для использования fgrep в определении списка строк, которые нужно искать.

2.1.1. Соглашения POSIX

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

1. В имени программы должно быть не менее двух и не более девяти символов.

2. Имена программ должны содержать лишь строчные символы и цифры.

3. Имя опции должно быть простым буквенно-цифровым символом. Опции с множеством цифр не должны допускаться. Для производителей, реализующих утилиты POSIX, опция -W зарезервирована для специфичных для производителя опций.

4. Все опции должны начинаться с символа '-'.

5. Для опций, не требующих аргументов, должно быть возможно объединение нескольких опций после единственного символа '-'. (Например, 'foo -a -b -c' и 'foo -abc' должны интерпретироваться одинаково.)

6. Когда опции все же требуется аргумент, он должен быть отделен от опции пробелом (например, 'fgrep -f patfile').

Однако, стандарт допускает историческую практику, при которой иногда опция и ее операнд могут находиться в одной строке: 'fgrep -fpatfile'. На практике функции getopt() и getopt_long() интерпретируют '-fpatfile' как '-f patfile', а не как '-f -p -a -t ...'.

7. Аргументы опций не должны быть необязательными.

Это означает, что если в документации программы указано, что опции требуется аргумент, этот аргумент должен присутствовать всегда, иначе программа потерпит неудачу GNU getopt() все же предусматривает необязательные аргументы опций, поскольку иногда они полезны

8. Если опция принимает аргумент, который может иметь несколько значений, программа должна получать этот аргумент в виде одной строки со значениями, разделенными запятыми или разделителем.

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

myprog -u "arnold,joe,jane" /* Разделение запятыми */

myprog -u "arnold joe jane" /* Разделение пробелами */

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

9. Опции должны находиться в командной строке первыми, перед операндами. Версии getopt() Unix проводят в жизнь это соглашение. GNU getopt() по умолчанию этого не делает, хотя вы можете настроить его на это.

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

11. Порядок, в котором приведены опции, не должен играть роли. Однако, для взаимно исключающих опций, когда одна опция перекрывает установки другой, тогда (так сказать) последняя побеждает. Если опция, имеющая аргумент, повторяется, программа должна обработать аргументы по порядку. Например, 'myprog -u arnold -u jane' то же самое, что и 'myprog -u "arnold, jane"'. (Вам придется осуществить это самостоятельно; getopt() вам не поможет.)

12. Нормально, когда порядок аргументов имеет для программы значение. Каждая программа должна документировать такие вещи.

13. Программы, читающие или записывающие именованные файлы, должны трактовать единственный аргумент '-' как означающий стандартный ввод или стандартный вывод, в зависимости от того, что подходит программе.

Отметим, что многие стандартные программы не следуют всем указанным соглашениям. Главной причиной является историческая совместимость; многие такие программы предшествовали систематизации этих соглашений.

2.1.2. Длинные опции GNU

Как мы видели в разделе 1.4.2 «Поведение программ», программам GNU рекомендуется использовать длинные опции в форме --help, --verbose и т.д. Такие опции, поскольку они начинаются с '--', не конфликтуют с соглашениями POSIX. Их также легче запомнить, и они предоставляют возможность последовательности среди всех утилит GNU. (Например, --help является везде одним и тем же, в отличие от -h для «help», -i для «information» и т.д.) Длинные опции GNU имеют свои собственные соглашения, реализованные в функции getopt_long():

1. У программ, реализующих инструменты POSIX, каждая короткая опция (один символ) должна иметь также свой вариант в виде длинной опции.

2. Дополнительные специфические для GNU опции не нуждаются в соответствующей короткой опции, но мы рекомендуем это сделать.

3. Длинную опцию можно сократить до кратчайшей строки, которая остается уникальной. Например, если есть две опции --verbose и --verbatim, самыми короткими сокращениями будут --verbo и --verba.

4. Аргументы опции отделяются от длинных опций либо разделителем, либо символом =. Например, --sourcefile=/some/file или --sourcefile /some/file.

5. Опции и аргументы могут быть заинтересованы в операндах командной строки, getopt_long() переставляет аргументы таким образом, что сначала обрабатываются все опции, а затем все операнды доступны последовательно. (Такое поведение можно запретить.)

6. Аргументы опций могут быть необязательными. Для таких опций считается, что аргумент присутствует, если он находится в одной строке с опцией. Это работает лишь для коротких опций. Например, если -х такая опция и дана строка 'foo -хYANKEES -y', аргументом -х является 'YANKEES'. Для 'foo -х -y' у -х нет аргументов.

7. Программы могут разрешить длинным опциям начинаться с одной черточки (Это типично для многих программ X Window.)

Многое из этого станет яснее, когда позже в этой главе мы рассмотрим getopt_long().

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

Программа на С получает доступ к своим аргументам командной строки через параметры argc и argv. Параметр argc является целым, указывающим число имеющихся аргументов, включая имя команды. Есть два обычных способа определения main(), отличающихся способом объявления argc:

int main(int argc, char *argv[])  int main(int argc, char **argv)

{                                 {

...                                ...

}                                 }

Практически между двумя этими объявлениями нет разницы, хотя первое концептуально более понятно: argc является массивом указателей на символы. А второе определение технически более корректно, это то, что мы используем. На рис. 2.2 изображена эта ситуация.

Рис. 2.2. Память для argc

По соглашению, argv[0] является именем программы. (Детали см. в разделе 9.1.4.3. «Имена программ и argv[0]».) Последующие элементы являются аргументами командной строки. Последним элементом массива argv является указатель NULL.

argc указывает, сколько имеется аргументов; поскольку в С индексы отсчитываются с нуля, выражение 'argv[argc] == NULL' всегда верно. Из-за этого, особенно в коде для Unix, вы увидите различные способы проверки окончания списка аргументов, такие, как цикл с проверкой, что счетчик превысил argc, или 'argv[i] == 0', или '*argv != NULL' и т.д. Они все эквивалентны.

2.2.1. Программа

echo

V7

Возможно, простейшим примером обработки командной строки является программа V7 echo, печатающая свои аргументы в стандартный вывод, разделяя их пробелами и завершая символом конца строки. Если первым аргументом является -n, завершающий символ новой строки опускается. (Это используется для приглашений из сценариев оболочки.) Вот код:

1  #include

2

3  main(argc, argv) /*int main(int argc, char **argv)*/

4  int argc;

5  char *argv[];

6  {

7   register int i, nflg;

8

9   nflg = 0;

10  if (argc > 1 && argv[1][0] == && argv[1][1] == 'n') {

11   nflg++;

12   argc--;

13   argv++;

14  }

15  for (i=1; i

16   fputs(argv[i], stdout);

17   if (i < argc-1)

18   putchar(' ');

19  }

20  if (nflg == 0)

21   putchar('\n');

22  exit(0);

23 }

Всего 23 строки! Здесь есть два интересных момента. Во-первых, уменьшение argc и одновременное увеличение argv (строки 12 и 13) являются обычным способом пропуска начальных аргументов. Во-вторых, проверка наличия -n (строка 10) является упрощением. -no-newline-at-the-end также работает. (Откомпилируйте и проверьте это!)

Ручной разбор опций обычен для кода V7, поскольку функция getopt() не была еще придумана.

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

Примерно в 1980-х группа поддержки Unix для System III в AT&T заметила, что каждая программа Unix использовала для разбора аргументов свои собственные методики. Чтобы облегчить работу пользователей и программистов, они разработали большинство из перечисленных ранее соглашений. (Хотя изложение в System III справки для intro(1) значительно менее формально, чем в стандарте POSIX.)

Группа поддержки Unix разработала также функцию getopt(), вместе с несколькими внешними переменными, чтобы упростить написание кода, придерживающегося стандартных соглашений. Функция GNU getopt_long() предоставляет совместимую с getopt() версию, а также упрощает разбор длинных опций в описанной ранее форме.

2.3.1. Опции с одним символом

Функция getopt() объявлена следующим образом:

#include /*POSIX*/

int getopt(int argc, char *const argv[], const char *optstring);

extern char *optarg;

extern int optind, opterr, optopt;

Аргументы argc и argv обычно передаются непосредственно от main(). optstring является строкой символов опций. Если за какой-либо буквой в строке следует двоеточие, эта опция ожидает наличия аргумента.

Для использования getopt() вызывайте ее повторно из цикла while до тех пор, пока она не вернет -1. Каждый раз, обнаружив действительный символ опции, функция возвращает этот символ. Если опция принимает аргумент, указатель на него помещается в переменную optarg. Рассмотрим программу, принимающую опцию -а без аргумента и опцию -b с аргументом:

int ос; /* символ опции */

char *b_opt_arg;

while ((ос = getopt(argc, argv, "ab:")) != -1) {

 switch (oc) {

 case 'a':

  /* обработка -а, установить соответствующий флаг */

  break;

 case 'b':

  /* обработка -b, получить значение аргумента из optarg */

  b_opt_arg = optarg;

  break;

 case ':':

  ... /* обработка ошибок, см. текст */

 case '?':

 default:

  ... /* обработка ошибок, см. текст */

 }

}

В ходе работы getopt() устанавливает несколько переменных, контролирующих обработку ошибок:

char *optarg

Аргумент для опции, если она принимает аргумент.

int optind

Текущий индекс в argv. Когда цикл loop завершается, оставшиеся операнды находятся с argv[optind] по argv[argc-1]. (Помните, что 'argv [argc] ==NULL'.)

int opterr

Когда эта переменная не равна нулю (значение по умолчанию), getopt() печатает свои собственные сообщения для недействительных опций или отсутствующих аргументов опций.

int optopt

Когда находится недействительный символ опции, getopt() возвращает либо '?', либо ':' (см ниже), a optopt содержит обнаруженный недействительный символ.

Люди есть люди, программы неизбежно будут иногда вызываться неправильно либо с недействительной опцией, либо с отсутствующим аргументом опции. Обычно в таких случаях getopt() выводит свои собственные сообщения и возвращает символ '?'. Однако, вы можете изменить такое поведение двумя способами.

Во-первых, записав 0 в opterr перед вызовом getopt(), можно заставить getopt() не предпринимать при обнаружении проблем никаких действий.

Во-вторых, если первый символ в optstring является двоеточием, getopt() не предпринимает никаких действий и возвращает другой символ в зависимости от ошибки следующим образом:

Неверная опция

getopt() возвращает '?', a optopt содержит неверный символ опции (Это обычное поведение).

Отсутствует аргумент опции

getopt() возвращает ':'. Если первый символ optstring не является двоеточием, getopt() возвращает '?', делая этот случай неотличимым от случая неверной опции.

Таким образом, помещение в качестве первого символа optstring двоеточия является хорошей мыслью, поскольку это позволяет различать «неверную опцию» и «отсутствующий аргумент опции». Расплатой за это является то, что getopt() в этом случае также не предпринимает никаких действий, заставляя вас выводить собственные сообщения об ошибках. Вот предыдущий пример, на этот раз с обработкой ошибок:

int ос; /* символ опции */

char *b_opt_arg;

while ((ос = getopt(argc, argv, ":ab:")) != -1) {

 switch (oc) {

 case 'a':

  /* обработка -a, установка соответствующего флага */

  break;

 case 'b':

  /* обработка -b, получение значения аргумента из optarg */

  b_opt_arg = optarg;

  break;

 case ':':

  /* отсутствует аргумент опции */

  fprintf(stderr, "%s: option '-%c' requires an argument\n",

   argv[0], optopt);

  break;

 case '?':

 default:

  /* недействительная опция */

  fprintf(stderr, "%s: option '-%c' is invalid: ignored\n",

   argv[0], optopt);

  break;

 }

}

Замечание о соглашениях по именованию флагов или опций: в большом количестве кода для Unix используются имена в виде xflg для любого данного символа опции x (например, nflg в echo V7; обычным является также xflag). Это может быть замечательным для авторе программы, который без проверки документации знает, что означает опция x. Но это не подходит для кого-то еще, кто пытается прочесть код и не знает наизусть значений всех символов опций. Гораздо лучше использовать имена, передающие смысл опции, как no_newline для опции -n echo.

2.3.2. GNU

getopt()

и порядок опций

Стандартная функция getopt() прекращает поиск опций, как только встречает аргумент командной строки, который не начинается с GNU getopt() отличается: она просматривает в поисках опций всю командную строку. По мере продвижения она переставляет элементы argv, так что после ее завершения все опции оказываются переставленными в начало, и код, продолжающий разбирать аргументы с argv[optind] до argv[argc-1], работает правильно. Во всех случаях специальный аргумент '--' завершает сканирование опций.

Вы можете изменить поведение по умолчанию, использовав в optstring специальный первый символ следующим образом:

optstring[0] == '+'

GNU getopt() ведет себя, как стандартная getopt(); она возвращает опции по мере их обнаружения, останавливаясь на первом аргументе, не являющемся опцией. Это работает также в том случае, если в окружении присутствует строка POSIXLY_CORRECT.

optstring[0] == '-'

GNU getopt() возвращает каждый аргумент командной строки независимо от того, представляет он аргумент или нет. В этом случае для каждого такого аргумента функция возвращает целое 1, а указатель на соответствующую строку помещает в optarg.

Как и для стандартной getopt(), если первым символом optstring является ':', GNU getopt() различает «неверную опцию» и «отсутствующий аргумент опции», возвращая соответственно '?' или ':'. Символ ':' в optstring может быть вторым символом, если первым символом является '+' или '-'.

Наконец, если за символом опции в optstring следуют два двоеточия, эта опция может иметь необязательный аргумент. (Быстро повторите это три раза!) Такой аргумент считается присутствующим, если он находится в том же элементе argv, что и сама опция, и отсутствующим в противном случае. В случае отсутствия аргумента GNU getopt() возвращает символ опции, а в optarg записывает NULL. Например, пусть имеем:

while ((с = getopt(argc, argv, "ab::")) != -1)

...

для -bYANKEES, возвращаемое значение будет 'b', a optarg указывает на «YANKEES», тогда как для -b или '-b YANKEES' возвращаемое значение будет все то же 'b', но в optarg будет помещен NULL. В последнем случае «YANKEES» представляет отдельный аргумент командной строки.

2.3.3. Длинные опции

Окружение представляет собой набор пар вида 'имя = значение ' для каждой программы. Эти пары называются переменными окружения. Каждое имя состоит от одной до любого числа буквенно-цифровых символов или символов подчеркивания ('_'), но имя не может начинаться с цифры. (Это правило контролируется оболочкой; С API может помешать в окружение все, что захочет, за счет возможного запутывания последующих программ.)

Переменные окружения часто используются для управления поведением программ. Например, если в окружении существует POSIXLY_CORRECT, многие программы запрещают расширения или историческое поведение, которые несовместимы со стандартом POSIX.

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

Конечно, недостатком использования переменных окружения является то, что они могут молча изменять поведение программы. Джим Мейеринг (Jim Meyering), сопроводитель Coreutils, выразил это таким образом:

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

2.4.1. Функции управления окружением

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

#include

char *getenv(const char *name);

/* ISO С: Получить переменную

   окружения */

int setenv(const char *name, /* POSIX: Установить переменную */

           const char *value, /* окружения */

           int overwrite);

int putenv(char *string); /* XSI: Установить переменную

                             окружения, использует строку */

void unsetenv(const char *name); /* POSIX: Удалить переменную

                                    окружения */

int clearenv(void); /* Общее: очистить все окружение */

Функция getenv() — та, которую вы будете использовать в 99% случаев. Ее аргументом является имя переменной окружения, которую нужно искать, такое, как «НОМЕ» или «PATH». Если переменная существует, getenv() возвращает указатель на строковое значение. Если нет, возвращается NULL. Например:

char *pathval;

/* Поиск PATH; если нет, использовать значение

   по умолчанию */

if ((pathval = getenv("PATH")) == NULL)

 pathval = "/bin:/usr/bin:/usr/ucb";

Иногда переменная окружения существует, но с пустым значением. В этом случае возвращаемое значение не равно NULL, но первый символ, на которую оно указывает, будет нулевым байтом, который в С является символом конца строки, '\0'. Ваш код должен позаботиться проверить, что возвращаемое значение не равно NULL. Если оно не NULL, необходимо также проверить, что строка не пустая, если вы хотите для чего-то использовать значение переменной. В любом случае, не используйте возвращенное значение слепо.

Для изменения переменной окружения или добавления к окружению еще одной используется setenv():

if (setenv("PATH", "/bin:/usr/bin:/usr/ucb", 1) != 0) {

 /* обработать ошибку */

}

Возможно, что переменная уже существует в окружении. Если третий аргумент равен true (не ноль), новое значение затирает старое. В противном случае, предыдущее значение не меняется. Возвращаемое значение равно -1, если для новой переменной не хватило памяти, и 0 в противном случае. setenv() для сохранения в окружении делает индивидуальные копии как имени переменной, так и нового ее значения

Более простой альтернативой setenv() является putenv(), которая берет одну строку «имя = значение » и помещает ее в окружение:

if (putenv("PATH=/bin:/usr/bin:/usr/ucb") != 0) {

 /* обработать ошибку */

}

putenv() слепо заменяет любые предшествующие значения для той же переменной. А также, и это, возможно, более важно, строка, переданная putenv(), помещается непосредственно в окружение. Это означает, что если ваш код позже изменит эту строку (например, если это был массив, а не строковая константа), окружение также будет изменено. Это, в свою очередь, означает, что вам не следует использовать в качестве параметров для putenv() локальную переменную. По всем этим причинам setenv() является более предпочтительной функцией.

ЗАМЕЧАНИЕ . GNU putenv() имеет дополнительную (документированную) особенность в своем поведении. Если строка аргумента является именем без следующего за ним символа = , именованная переменная удаляется. Программа GNU env , которую мы рассмотрим далее в мой главе, полагается на такое поведение.

Функция unsetenv() удаляет переменную из окружения:

unsetenv("PATH");

Наконец, функция clearenv() полностью очищает окружение:

if (clearenv() != 0) {

 /* обработать ошибку */

}

Эта функция не стандартизирована POSIX, хотя она доступна в GNU/Linux и нескольких коммерческих вариантах Unix. Ее следует использовать, если приложение должно быть очень безопасным и нужно построить собственное окружение с нуля. Если clearenv() недоступна, в справке GNU/Linux для clearenv(3) рекомендуется использовать для выполнения этой задачи 'environ = NULL'.

2.4.2. Окружение в целом:

environ

Правильным способом работы с окружением является использование функций, описанных в предыдущем разделе. Однако, стоит взглянуть на то, как это работает «под капотом».

Внешняя переменная environ предоставляет доступ таким же способом, как argv предоставляет доступ к аргументам командной строки. Вы сами должны объявить переменную. Хотя она и стандартизирована POSIX, environ намеренно не объявлена ни в одном стандартном заголовочном файле (Это, кажется, прослеживается из исторической практики.) Вот объявление:

extern char **environ; /* Смотрите, нет заголовочного файла POSIX */

Как и в argv, завершающим элементом environ является NULL. Однако, здесь нет переменной «числа строк окружения», которая соответствовала бы argc. Следующая простая программа распечатывает все окружение:

/* ch02-printenv.c --- Распечатать окружение. */

#include

extern char **environ;

int main(int argc, char **argv) {

 int i;

 if (environ != NULL)

  for (i = 0; environ[i] != NULL; i++)

   printf("%s\n", environ[i]);

 return 0;

}

Хотя это и маловероятно, перед попыткой использовать environ эта программа проверяет, что она не равна NULL.

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

В качестве уловки реализации можно получить доступ к окружению, объявив третий параметр main():

int main(int argc, char **argv, char **envp) {

 ...

}

Затем можно использовать envp также, как environ. Хотя это иногда можно увидеть в старом коде, мы не рекомендуем такое использование; environ является официальным, стандартным, переносимым способом получения доступа ко всему окружению, если это вам необходимо.

2.4.3. GNU

env

Чтобы завершить главу, рассмотрим GNU версию команды env. Эта команда добавляет переменные к окружению в ходе выполнения одной команды. Она может использоваться также для очищения окружения в ходе этой команды или для удаления отдельных переменных окружения. Программа обеспечивает нас двойной функциональностью, поскольку проявляет возможности как getopt_long(), так и несколько других возможностей, обсуждавшихся в этом разделе. Вот как вызывается программа:

$ env --help

Usage: env [OPTION]... [-] [NAME=VALUE]... [COMMAND [ARG]...]

/* Устанавливает соответствующее VALUE для каждого NAME и запускает COMMAND */

-i, --ignore-environment /* запустить с пустым окружением */

-u, --unset=NAME         /* удалить переменную из окружения */

--help                   /* показать этот экран справки и выйти */

--version                /* вывести информацию о версии и выйти */

/* Простое - предполагает -1. Если не указана COMMAND, отображает

   имеющееся окружение.

Об ошибках сообщайте в . */

Вот несколько примеров вызовов команды:

$ env - myprog arg1 /* Очистить окружение, запустить программу с args */

$ env - РАТН=/bin:/usr/bin myprog arg1 /* Очистить окружение, добавить PATH, запустить программу */

$ env -u IFS PATH=/bin:/usr/bin myprog arg1 /* Сбросить IFS, добавить PATH, запустить программу */

Код начинается со стандартной формулировки авторских прав GNU и разъясняющего комментария. Мы для краткости их опустили. (Формулировка авторского права обсуждается в Приложении С «Общедоступная лицензия GNU». Показанного ранее вывода --help достаточно для понимания того, как работает программа.) За объявленным авторским правом и комментарием следуют подключаемые заголовочные файлы и объявления. Вызов макроса 'N_("string")' (строка 93) предназначен для использования при локализации программного обеспечения, тема, освещенная в главе 13 «Интернационализация и локализация». Пока вы можете рассматривать его, как содержащий строковую константу.

80  #include

81  #include

82  #include

83  #include

84  #include

85

86  #include "system.h"

87  #include "error.h"

88  #include "closeout.h"

89

90  /* Официальное имя этой программы (напр., нет префикса 'g'). */

91  #define PROGRAM_NAME "env"

92

93  #define AUTHORS N_ ("Richard Mlynarik and David MacKenzie")

94

95  int putenv();

96

97  extern char **environ;

98

99  /* Имя, посредством которого эта программа была запущена. */

100 char *program_name;

101

102 static struct option const longopts[] =

103  {

104  {"ignore-environment", no_argument, NULL, 'i'},

105  {"unset", required_argument, NULL, 'u'},

106  {GETOPT_HELP_OPTION_DECL},

107  {GETOPT_VERSION_OPTION_DECL},

108  {NULL, 0, NULL, 0}

109 };

GNU Coreutils содержит большое число программ, многие из которых выполняют одни и те же общие задачи (например, анализ аргументов). Для облегчения сопровождения многие типичные идиомы были определены в виде макросов. Двумя таким макросами являются GETOPT_HELP_OPTION_DECL и GETOPT_VERSION_OPTION (строки 106 и 107). Вскоре мы рассмотрим их определения. Первая функция, usage(), выводит информацию об использовании и завершает программу. Макрос _("string") (строка 115, используется также по всей программе) также предназначен для локализации, пока также считайте его содержащим строковую константу.

111 void

112 usage(int status)

113 {

114  if (status '= 0)

115   fprintf(stderr, _("Try '%s --help' for more information.\n"),

116    program_name);

117  else

118  {

119   printf (_("\

120    Usage: %s [OPTION]... [-] [NAME=VALUE]... [COMMAND [ARG]...]\n"),

121    program_name);

122   fputs (_("\

123    Set each NAME to VALUE in the environment and run COMMAND. \n\

124    \n\

125    -i, --ignore-environment start with an empty environment\n\

126    -u, --unset=NAME remove variable from the environment\n\

127    "), stdout);

128   fputs(HELP_OPTION_DESCRIPTION, stdout);

129   fputs(VERSION_OPTION_DESCRIPTION, stdout);

130   fputs(_("\

131    \n\

132    A mere - implies -i. If no COMMAND, print the resulting\

133    environment.\n"), stdout);

134   printf(_("\nReport bugs to <%s>.\n"), PACKAGE_BUGREPORT);

135  }

136  exit(status);

137 }

Первая часть main() объявляет переменные и настраивает локализацию. Функции setlocale(), bindtextdomain() и textdomain() (строки 147–149) обсуждаются в главе 13 «Интернационализация и локализация». Отметим, что эта программа использует аргумент main() envp (строка 140). Это единственная программа Coreutils, которая так делает. Наконец, вызов atexit() в строке 151 (см. раздел 9.1.5.3. «Функции завершения») регистрирует библиотечную функцию Coreutils, которая очищает все выходные буферы и закрывает stdout, выдавая сообщение при ошибке. Следующая часть программы обрабатывает аргументы командной строки, используя getopt_long().

139 int

140 main(register int argc, register char **argv, char **envp)

141 {

142  char *dummy_environ[1];

143  int optc;

144  int ignore_environment = 0;

145

146  program_name = argv[0];

147  setlocale(LC_ALL, "");

148  bindtextdomain(PACKAGE, LOCALEDIR);

149  textdomain(PACKAGE);

150

151  atexit(close_stdout);

152

153  while ((optc = getopt_long(argc, argv, "+iu:", longopts, NULL)) != -1)

154  {

155   switch (optc)

156   {

157   case 0:

158    break;

159   case 'i':

160    ignore_environment = 1;

161    break;

162   case 'u':

163    break;

164   case_GETOPT_HELP_CHAR;

165   case_GETOPT_VERSION_CHAR(PROGRAM_NAME, AUTHORS);

166   default:

167    usage(2);

168   }

169  }

170

171  if (optind != argc && !strcmp(argv[optind], "-"))

172   ignore_environment = 1;

Вот отрывок из файла src/sys2.h в дистрибутиве Coreutils с упомянутыми ранее определениями и макросом 'case_GETOPT_xxx', использованным выше (строки 164–165):

/* Вынесение за скобки общей части кода, обрабатывающего --help и

   --version. */

/* Эти значения перечисления никак не могут конфликтовать со значениями опций,

   обычно используемыми командами, включая CHAR_MAX + 1 и т.д. Избегайте

   CHAR_MIN - 1, т.к. оно может равняться -1, значение завершения опций getopt.

*/

enum {

 GETOPT_HELP_CHAR = (CHAR_MIN — 2),

 GETOPT_VERSION_CHAR = (CHAR_MIN - 3)

};

#define GETOPT_HELP_OPTION_DECL \

 "help", no_argument, 0, GETOPT_HELP_CHAR

#define GETOPT_VERSION_OPTION_DECL \

 "version", no_argument, 0, GETOPT_VERSION_CHAR

#define case_GETOPT_HELP_CHAR \

 case GETOPT_HELP_CHAR: \

  usage(EXIT_SUCCESS); \

  break;

#define case_GETOPT_VERSION_CHAR(Program_name, Authors) \

 case GETOPT_VERSION_CHAR: \

  version_etc(stdout, Program_name, PACKAGE, VERSION, Authors); \

  exit(EXIT_SUCCESS); \

  break;

Результатом этого кода является печать сообщения об использовании утилиты для --help и печать информации о версии для --version. Обе опции завершаются успешно («Успешный» и «неудачный» статусы завершения описаны в разделе 9.1.5.1 «Определение статуса завершения процесса».) Поскольку в Coreutils входят десятки утилит, имеет смысл вынести за скобки и стандартизовать как можно больше повторяющегося кода.

Возвращаясь к env.с:

174 environ = dummy_environ;

175 environ[0] = NULL;

176

177 if (!ignore_environment)

178  for (; *envp; envp++)

179   putenv(*envp);

180

181 optind = 0; /* Принудительная реинициализация GNU getopt. */

182 while ((optc = getopt_long(argc, argv, "+iu:", longopts, NULL)) != -1)

183  if (optc == 'u')

184   putenv(optarg); /* Требуется GNU putenv. */

185

186 if (optind !=argc && !strcmp(argv[optind], "-")) /* Пропустить опции */

187  ++optind;

188

189 while (optind < argc && strchr(argv[optind], '=')) /* Установить

     переменные окружения * /

190 putenv(argv[optind++]);

191

192 /* Если программа не указана, напечатать переменные окружения и выйти. */

193 if (optind == argc)

194 {

195  while (*environ)

196   puts (*environ++);

197  exit(EXIT_SUCCESS);

198 }

Строки 174–179 переносят существующие переменные в новую копию окружения. В глобальную переменную environ помещается указатель на пустой локальный массив. Параметр envp поддерживает доступ к первоначальному окружению.

Строки 181–184 удаляют переменные окружения, указанные в опции -u. Программа осуществляет это, повторно сканируя командную строку и удаляя перечисленные там имена. Удаление переменных окружения основывается на обсуждавшейся ранее особенности GNU putenv(): при вызове с одним лишь именем переменной (без указанного значения) putenv() удаляет ее из окружения.

После опций в командной строке помещаются новые или замещающие переменные окружения. Строки 189–190 продолжают сканирование командной строки, отыскивая установки переменных окружения в виде 'имя = значение '.

По достижении строки 192, если в командной строке ничего не осталось, предполагается, что env печатает новое окружение и выходит из программы. Она это и делает (строки 195–197).

Если остались аргументы, они представляют имя команды, которую нужно вызвать, и аргументы для передачи этой новой команде. Это делается с помощью системного вызова execvp() (строка 200), который замещает текущую программу новой. (Этот вызов обсуждается в разделе 9.1.4 «Запуск новой программы: семейство exec()»; пока не беспокойтесь о деталях.) Если этот вызов возвращается в текущую программу, он потерпел неудачу. В таком случае env выводит сообщение об ошибке и завершает программу.

200  execvp(argv[optind], &argv[optind]);

201

202  {

203   int exit_status = (errno == ENOENT ? 127 : 126);

204   error(0, errno, "%s", argv[optind]);

205   exit(exit_status);

206  }

207 }

Значения кода завершения 126 и 127 (определяемые в строке 203) соответствуют стандарту POSIX. 127 означает, что программа, которую execvp() попыталась запустить, не существует. (ENOENT означает, что файл не содержит записи в каталоге.) 126 означает, что файл существует, но была какая-то другая ошибка.

Четыре библиотечные функции образуют основу управления динамической памятью С Мы опишем сначала их, затем последуют описания двух системных вызовов, поверх которых построены эти библиотечные функции. Библиотечные функции С, в свою очередь, обычно используются для реализации других выделяющих память библиотечных функций и операторов C++ new и delete.

Наконец, мы обсудим функцию, которую часто используют, но которую мы не рекомендуем использовать.

3.2.1. Библиотечные вызовы:

malloc()

,

calloc()

,

realloc()

,

free()

3.2.2. Копирование строк:

strdup()

Одной чрезвычайно типичной операцией является выделение памяти для копирования строки. Это настолько типично, что многие программисты предусматривают для нее простую функцию вместо использования внутритекстового кодирования, и часто эта функция называется strdup():

#include

/* strdup --- выделить память с malloc() и скопировать строку */

char *strdup(const char *str) {

 size_t len;

 char *copy;

 len = strlen(str) + 1;

 /* включить место для завершающего '\0' */

 copy = malloc(len);

 if (copy != NULL) strcpy(copy, str);

 return copy; /* при ошибке возвращает NULL */

}

С появлением стандарта POSIX 2001 программисты по всему миру могут вздохнуть свободнее: эта функция является теперь частью POSIX в виде расширения XSI:

#include /* XSI */

char *strdup(const char *str); /* Копировать str */

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

3.2.3. Системные вызовы:

brk()

и

sbrk()

Четыре функции, которые мы рассмотрели (malloc(), calloc(), realloc() и free()) являются стандартными, переносимыми функциями для управления динамической памятью.

На Unix-системах стандартные функции реализованы поверх двух дополнительных, очень примитивных процедур, которые непосредственно изменяют размер адресного пространства процесса. Мы представляем их здесь, чтобы помочь вам понять, как работают GNU/Linux и Unix (снова «под капотом»); крайне маловероятно, что вам когда-нибудь понадобится использовать эти функции в обычных программах. Они определены следующим образом:

#include /* Обычный */

#include /* Необходим для систем GLIBC 2 */

int brk(void *end_data_segment);

void *sbrk(ptrdiff_t increment);

Системный вызов brk() действительно изменяет адресное пространство процесса. Адрес является указателем, представляющим окончание сегмента данных (на самом деле, области кучи, как было показано ранее на рис. 3.1). Ее аргумент является абсолютным логическим адресом, представляющим новое окончание адресного пространства. В случае успеха функция возвращает 0, а в случае неуспеха (-1).

Функцию sbrk() использовать проще; ее аргумент является числом байтов, на которое нужно увеличить адресное пространство. Вызвав ее с приращением 0, можно определить, где в настоящее время заканчивается адресное пространство. Таким образом, чтобы увеличить адресное пространство на 32 байта, используется код следующего вида:

char *p = (char*)sbrk(0); /* получить текущий конец адресного

                             пространства */

if (brk(p + 32) < 0) {

 /* обработать ошибку */

}

/* в противном случае, изменение сработало */

Практически, вам не нужно непосредственно использовать brk(). Вместо этого используется исключительно sbrk() для увеличения (или даже сокращения) адресного пространства. (Вскоре мы покажем, как это делать, в разделе 3.2.5. «Исследование адресного пространства».)

Еще более практично вообще никогда не использовать эти процедуры. Программа, которая их использует, не может затем использовать также и malloc(), и это создает большую проблему, поскольку многие элементы стандартной библиотеки полагаются на использование malloc(). Поэтому использование brk() или sbrk() может приводить к трудно обнаруживаемым крушениям программы.

Но знать о низкоуровневых механизмах стоит, и конечно же, набор функций malloc() реализован с помощью sbrk() и brk().

3.2.4. Вызовы ленивых программистов:

alloca()

Есть еще одна дополнительная функция выделения памяти, о которой вам нужно знать. Мы обсуждаем ее лишь для того, чтобы вы поняли ее, когда увидите, но не следует использовать ее в новых программах! Эта функция называется alloca(); она объявлена следующим образом:

/* Заголовок в GNU/Linux, возможно, не на всех Unix-системах */

#include /* Обычный */

void *alloca(size_t size);

Функция alloca() выделяет size байтов из стека. Хорошо, что выделенная память исчезает после возвращения из функции. Нет необходимости явным образом освобождать память, поскольку это осуществляется автоматически, как в случае с локальными переменными.

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

• Функция не является стандартной; она не включена ни в какой стандарт, ни в ISO, ни в С или POSIX.

• Функция не переносима. Хотя она существует на многих системах Unix и GNU/Linux, она не существует на не-Unix системах. Это проблема, поскольку код часто должен быть многоплатформенным, выходя за пределы просто Linux и Unix.

• На некоторых системах alloca() невозможно даже реализовать. Весь мир не является ни процессором Intel x86, ни GCC.

• Цитируя справку (добавлено выделение): «Функция alloca зависит от машины и от компилятора. На многих системах ее реализация ошибочна. Ее использование не рекомендуется».

• Снова цитируя справку: «На многих системах alloca не может быть использована внутри списка аргументов вызова функции, поскольку резервируемая в стеке при помощи alloca память оказалась бы в середине стека в пространстве для аргументов функции».

• Она потворствует неряшливому программированию. Тщательная и корректная работа с памятью не сложна; вам просто нужно подумать о том, что вы делаете, и планировать заранее.

GCC обычно использует встроенную версию функции, которая действует с использованием внутритекстового (inline) кода. В результате есть другие последствия alloca(). Снова цитируя справку:

Факт, что код является внутритекстовым (inline), означает, что невозможно получить адрес этой функции или изменить ее поведение путем компоновки с другой библиотекой.

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

Справочная страница не углубляется в описание проблемы со встроенной alloca() GCC. Если есть переполнение стека, возвращаемое значение является мусором. И у вас нет способа сообщить об этом! Это упущение делает невозможным использование GCC alloca() в устойчивом коде.

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

3.2.5. Исследование адресного пространства

Следующая программа, ch03-memaddr.c, подводит итог всему, что мы узнали об адресном пространстве. Она делает множество вещей, которые не следует делать на практике, таких, как вызовы alloca() или непосредственные вызовы brk() и sbrk().

1  /*

2   * ch03-memaddr.с --- Показать адреса секций кода, данных и стека,

3   * а также BSS и динамической памяти.

4   */

5

6  #include

7  #include /* для определения ptrdiff_t в GLIBC */

8  #include

9  #include /* лишь для демонстрации */

10

11 extern void afunc(void); /* функция, показывающая рост стека */

12

13 int bss_var; /* автоматически инициализируется в 0, должна быть в BSS */

14 int data_var = 42; /* инициализируется в не 0, должна быть

15                       в сегменте данных */

16 int

17 main(int argc, char **argv) /* аргументы не используются */

18 {

19  char *p, *b, *nb;

20

21  printf("Text Locations:\n");

22  printf("\tAddress of main: %p\n", main);

23  printf("\tAddress of afunc: %p\n", afunc);

24

25  printf("Stack Locations.\n");

26  afunc();

27

28  p = (char*)alloca(32);

29  if (p != NULL) {

30   printf("\tStart of alloca()'ed array: %p\n", p);

31   printf("\tEnd of alloca()'ed array: %p\n", p + 31);

32  }

33

34  printf("Data Locations:\n");

35  printf("\tAddress of data_var: %p\n", &data_var);

36

37  printf("BSS Locations:\n");

38  printf("\tAddress of bss_var: %p\n", &bss_var);

39

40  b = sbrk((ptrdiff_t)32); /* увеличить адресное пространство */

41  nb = sbrk((ptrdiff_t)0);

42  printf("Heap Locations:\n");

43  printf("\tInitial end of heap: %p\n", b);

44  printf("\tNew end of heap: %p\n", nb);

45

46  b = sbrk((ptrdiff_t)-16); /* сократить его */

47  nb = sbrk((ptrdiff_t)0);

48  printf("\tFinal end of heap: %p\n", nb);

49 }

50

51 void

52 afunc(void)

53 {

54  static int level = 0; /* уровень рекурсии */

55  auto int stack_var; /* автоматическая переменная в стеке */

56

57  if (++level == 3) /* избежать бесконечной рекурсии */

58   return;

59

60  printf("\tStack level %d: address of stack_var: %p\n",

61   level, &stack_var);

62  afunc(); /* рекурсивный вызов */

63 }

Эта программа распечатывает местонахождение двух функций main() и afunc() (строки 22–23). Затем она показывает, как стек растет вниз, позволяя afunc() (строки 51–63) распечатать адреса последовательных экземпляров ее локальной переменной stack_var. (stack_var намеренно объявлена как auto, чтобы подчеркнуть, что она находится в стеке.) Затем она показывает расположение памяти, выделенной с помощью alloca() (строки 28–32). В заключение она печатает местоположение переменных данных и BSS (строки 34–38), а затем памяти, выделенной непосредственно через sbrk() (строки 40–48). Вот результаты запуска программы на системе Intel GNU/Linux:

$ ch03-memaddr

Text Locations:

 Address of main: 0x804838c

 Address of afunc: 0x80484a8

Stack Locations:

 Stack level 1: address of stack_var: 0xbffff864

 Stack level 2: address of stack_var: 0xbffff844

  /* Стек растет вниз */

 Start of alloca()'ed array: 0xbffff860

 End of alloca()'ed array: 0xbffff87f

  /* Адреса находятся в стеке */

Data Locations:

 Address of data_var: 0x80496b8

BSS Locations:

 Address of bss_var: 0x80497c4

  /* BSS выше инициализированных данных */

Heap Locations:

 Initial end of heap: 0x80497c8

  /* Куча непосредственно над BSS */

 New end of heap: 0x80497e8

  /* И растет вверх */

 Final end of heap: 0x80497d8

  /* Адресные пространства можно сокращать */

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

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

int result;

result = some_system_call(param1, param2);

if (result < 0) {

 /* ошибка, что-нибудь сделать */

} else

 /* все нормально, продолжить */

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

#include /* ISO С */

extern int errno;

Хотя сама errno может быть макросом, который действует подобно переменной int — она не обязательно является действительной целой переменной. В частности, в многопоточном окружении у каждого потока будет своя индивидуальная версия errno. Несмотря на это, практически для всех системных вызовов и функций в данной книге вы можете рассматривать errno как простую int.

4.3.1. Значения

errno

Стандарт POSIX 2001 определяет большое число возможных значений для errno. Многие из них относятся к сетям, IPC или другим специальным задачам. Справочная страница для каждого системного вызова описывает возможные значения errno, которые могут иметь место; поэтому вы можете написать код для проверки отдельных ошибок и соответствующим образом обработать их, если это нужно. Возможные значения определены через символические имена. Предусмотренные GLIBC значения перечислены в табл. 4.1.

Таблица 4.1. Значения GLIBC для errno

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

ЗАМЕЧАНИЕ . errno следует проверять лишь после того, как возникла ошибка и до того, как сделаны дальнейшие системные вызовы. Начальное значение той переменной 0. Однако, в промежутках между ошибками ничто не изменяет ее значения, это означает, что успешный системный вызов не восстанавливает значение 0. Конечно, вы можете вручную установить ее в 0 в самом начале или когда захотите, однако это делается редко.

Сначала мы используем errno лишь для сообщений об ошибках. Для этого имеются две полезные функции. Первая — perror():

#include /* ISO С */

void perror(const char *s);

Функция perror() выводит предоставленную программой строку, за которой следует двоеточие, а затем строка, описывающая значение errno:

if (some_system_call(param1, param2) < 0) {

 perror("system call failed");

 return 1;

}

Мы предпочитаем функцию strerror(), которая принимает параметр со значением ошибки и возвращает указатель на строку с описанием ошибки:

#include /* ISO С */

char *strerror(int errnum);

strerror() предоставляет для сообщений об ошибках максимальную гибкость, поскольку fprintf() дает возможность выводить ошибки любым нужным нам способом, наподобие этого.

if (some_system_call(param1, param2) < 0) {

 fprintf(stderr, "%s: %d, %d: some_system_call failed: %s\n",

  argv[0], param1, param2, strerror(errno));

 return 1;

}

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

4.3.2. Стиль сообщения об ошибках

Для использования в сообщениях об ошибках С предоставляет несколько специальных макросов. Наиболее широкоупотребительными являются __FILE__ и __LINE__, которые разворачиваются в имя исходного файла и номер текущей строки в этом файле. В С они были доступны с самого начала. C99 определяет дополнительный предопределенный идентификатор, __func__, который представляет имя текущей функции в виде символьной строки. Макросы используются следующим образом:

if (some_system_call(param1, param2) < 0) {

 fprintf(stderr, "%s: %s (%s %d): some_system_call(%d, %d) failed: %s\n",

  argv[0], __func__, __FILE__, __LINE__,

  param1, param2, strerror(errno));

 return 1;

}

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

Таблица 4.2. Диагностические идентификаторы C99

Использование __FILE__ и __LINE__ было вполне обычно для ранних дней Unix, когда у большинства людей были исходные коды и они могли находить ошибки и устранять их. По мере того, как системы Unix становились все более коммерческими, использование этих идентификаторов постепенно уменьшалось, поскольку знание положения в исходном коде дает немного пользы, когда имеется лишь двоичный исполняемый файл.

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

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

4.4.1. Понятие о дескрипторах файлов

Дескриптор файла является целым значением. Действительные дескрипторы файлов начинаются с 0 и растут до некоторого установленного системой предела. Эти целые фактически являются индексами таблицы открытых файлов для каждого процесса (Таблица поддерживается внутри операционной системы; она недоступна запущенным программам.) В большинстве современных систем размеры таблиц большие. Команда 'ulimit -n' печатает это значение:

$ ulimit -n

1024

Из С максимальное число открытых файлов возвращается функцией getdtablesize() (получить размер таблицы дескрипторов):

#include /* Обычный */

int getdtablesize(void);

Следующая небольшая программа выводит результат работы этой функции:

/* ch04-maxfds.с --- Демонстрация getdtablesize(). */

#include /* для fprintf(), stderr, BUFSIZ */

#include /* для ssize_t */

int main(int argc, char **argv) {

 printf("max fds: %d\n", getdtablesize());

 exit(0);

}

Неудивительно, что после компиляции и запуска эта программа выводит то же значение, что и ulimit:

$ ch04-maxfds

max fds: 1024

Дескрипторы файлов содержатся в обычных переменных int; для использования с системными вызовами ввода/вывода можно увидеть типичные объявления вида 'int fd'. Для дескрипторов файлов нет предопределенного типа.

В обычном случае каждая программа начинает свою работу с тремя уже открытыми для нее дескрипторами файлов. Это стандартный ввод, стандартный вывод и стандартная ошибка, с дескрипторами файлов 0, 1 и 2 соответственно. (Если не было использовано перенаправление, каждый из них связан с клавиатурой и с экраном.)

Очевидные символические константы. Оксюморон?

При работе с системными вызовами на основе дескрипторов файлов и стандартных ввода, вывода и ошибки целые константы 0, 1 и 2 обычно используются прямо в коде. В подавляющем большинстве случаев использование таких символических констант (manifest constants) является плохой мыслью. Вы никогда не знаете, каково значение некоторой случайной целой константы и имеет ли к ней какое-нибудь отношение константа с тем же значением, использованная в другой части кода. С этой целью стандарт POSIX требует объявить следующие именованные константы (symbolic constants) в <unistd.h> :

STDIN_FILENO   «Номер файла» для стандартного ввода: 0.

STDOUT_FILENO  Номер файла для стандартного вывода: 1.

STDERR_FILENO  Номер файла для стандартной ошибки: 2.

Однако, по нашему скромному мнению, использование этих макросов избыточно. Во-первых, неприятно набирать 12 или 13 символов вместо 1. Во-вторых, использование 0, 1 и 2 так стандартно и так хорошо известно, что на самом деле нет никаких оснований для путаницы в смысле этих конкретных символических констант.

С другой стороны, использование этих констант не оставляет сомнений в намерениях программиста. Сравните это утверждение:

int fd = 0;

Инициализируется ли fd значением стандартного ввода, или же программист благоразумно инициализирует свои переменные подходящим значением? Вы не можете этого сказать.

Один из подходов (рекомендованный Джеффом Колье (Geoff Collyer)) заключается в использовании следующего определения enum :

enum { Stdin, Stdout, Stderr };

Затем эти константы можно использовать вместо 0, 1 и 2. Их легко читать и печатать.

4.4.2. Открытие и закрытие файлов

4.4.3. Чтение и запись

Ввод/вывод осуществляется системными вызовами read() и write() соответственно:

#include /* POSIX */

#include

#include

#include

ssize_t read(int fd, void *buf, size_t count);

ssize_t write(int fd, const void *buf, size_t count);

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

Возвращаемое значение является числом действительно прочитанных или записанных байтов. (Это число может быть меньше запрошенного: при операции чтения это происходит, когда в файле осталось меньше count байтов, а при операции записи это случается, когда диск заполнен или произошла еще какая-нибудь ошибка.) Возвращаемое значение -1 означает возникшую ошибку, в этом случае errno указывает эту ошибку. Когда read() возвращает 0, это означает, что достигнут конец файла.

Теперь мы можем показать оставшуюся часть кода для ch04-cat. Процедура process() использует 0 для стандартного ввода, если именем файла является «-» (строки 50 и 51). В противном случае она открывает данный файл:

36 /*

37   * process --- сделать что-то с файлом, в данном случае,

38   * послать его в stdout (fd 1).

39   * Возвращает 0, если все нормально; в противном случае 1.

40   */

41

42 int

43 process(char *file)

44 {

45  int fd;

46  ssize_t rcount, wcount;

47  char buffer[BUFSIZ];

48  int errors = 0;

49

50  if (strcmp(file, "-") == 0)

51   fd = 0;

52  else if ((fd = open(file, O_RDONLY)) < 0) {

53   fprintf(stderr, "%s: %s: cannot open for reading: %s\n",

54    myname, file, strerror(errno));

55   return 1;

56  }

Буфер buffer (строка 47) имеет размер BUFSIZ; эта константа определена В как «оптимальный» размер блока для ввода/вывода. Хотя значение BUFSIZ различается в разных системах, код, использующий эту константу, чистый и переносимый.

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

58 while ((rcount = read(fd, buffer, sizeof buffer)) > 0) {

59  wcount = write(1, buffer, rcount);

60  if (wcount != rcount) {

61   fprintf(stderr, "%s: %s: write error: %s\n",

62    myname, file, strerror(errno));

63   errors++;

64   break;

65  }

66 }

Переменные rcount и wcount (строка 45) имеют тип ssize_t, «знаковый size_t», который позволяет хранить в них отрицательные значения. Обратите внимание, что число байтов, переданное write(), является значением, возвращенным read() (строка 59). Хотя мы хотим читать порциями фиксированного размера в BUFSIZ, маловероятно, что размер самого файла кратен BUFSIZ. При чтении из файла завершающей, меньшей порции байтов, возвращаемое значение указывает, сколько байтов buffer получили новые данные. В стандартный вывод должны быть скопированы только эти байты, а не весь буфер целиком.

Условие 'wcount != rcount' в строке 60 является правильным способом проверки на ошибки; если были записаны некоторые, но не все данные, wcount будет больше нуля, но меньше rcount.

В заключение process() проверяет наличие ошибок чтения (строки 68–72), а затем пытается закрыть файл. В случае (маловероятном) неудачного завершения close() (строка 75) она выводит сообщение об ошибке. Избежание закрытия стандартного ввода не является абсолютно необходимым в данной программе, но является хорошей привычкой при разработке больших программ, в случае, когда другой код где-то в другом месте хочет что-то с ним делать или если порожденная программа будет наследовать его. Последний оператор (строка 82) возвращает 1, если были ошибки, и 0 в противном случае.

68  if (rcount < 0) {

69   fprintf(stderr, "%s: %s: read error: %s\n",

70    myname, file, strerror(errno));

71   errors++;

72  }

73

74  if (fd != 0) {

75   if (close(fd) < 0) {

76    fprintf(stderr, "%s: %s: close error: %s\n",

77     myname, file, strerror(errno));

78    errors++;

79   }

80  }

81

82  return (errors != 0);

83 }

ch04-cat проверяет на ошибки каждый системный вызов. Хотя это утомительно, зато предоставляет устойчивость (или по крайней мере, ясность): когда что-то идет не так, ch04-cat выводит сообщение об ошибке, которое специфично настолько, насколько это возможно. В сочетании с errno и strerror() это просто. Вот все с ch04-cat, всего 88 строк кода!

Для подведения итогов вот несколько важных моментов, которые нужно понять относительно ввода/вывода в Unix:

Ввод/вывод не интерпретируется

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

Ввод/вывод гибок

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

Ввод/вывод прост

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

Ввод/вывод может быть частичным

Как read(), так и write() могут переместить меньше байтов, чем запрошено. Код приложения (т.е. ваш код) всегда должен учитывать это.

4.4.4. Пример: Unix

cat

Как и было обещано, вот версия cat V7. Она начинается с проверки опций, cat V7 принимает единственную опцию, -u, для осуществления небуферированного вывода.

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

1  /*

2   * Объединение файлов.

3   */

4

5  #include

6  #include

7  #include

8

9  char stdbuf[BUFSIZ];

10

11 main(argc, argv) /* int main(int argc, char **argv) */

12 char **argv;

13 {

14  int fflg = 0;

15  register FILE *fi;

16  register c;

17  int dev, ino = -1;

18  struct stat statb;

19

20  setbuf(stdout, stdbuf);

21  for( ; argc>1 && argv[1][0] == '-'; argc--, argv++) {

22   switch(argv[1][1]) { /* Обработка опций */

23   case 0:

24    break;

25   case 'u':

26    setbuf(stdout, (char*)NULL);

27    continue;

28   }

29   break;

30  }

31  fstat(fileno(stdout), &statb); /* Строки 31-36 объясняются в главе 5 */

32  statb.st_mode &= S_IFMT;

33  if (statb.st_mode != S_IFCHR && statb.st_mode != S_IPBLK) {

34   dev = statb.st_dev;

35   ino = statb.st_ino;

36  }

37  if (argc < 2) {

38   argc = 2;

39   fflg++;

40  }

41  while (--argc > 0) { // Loop over files

42   if (fflg || (*++argv)[0] == '-' && (*argv)[1] == '\0')

43    fi = stdin;

44   else {

45    if ((fi = fopen(*argv, "r")) == NULL) {

46     fprintf(stderr, "cat: can't open %s\n", *argv);

47    continue;

48   }

49  }

50  fstat(fileno(fi), &statb); /* Строки 50-56 объясняются в главе 5 */

51  if (statb.st_dev == dev && statb.st_ino == ino) {

52   fprintf(stderr, "cat: input %s is output\n",

53    fflg ? "-" : *argv);

54   fclose(fi);

55   continue;

56  }

57  while ((c=getc(fi)) != EOF) /* Копировать содержимое в stdout */

58   putchar(с);

59  if (fi != stdin)

60   fclose(fi);

61  }

62  return(0);

63 }

Следует заметить, что программа всегда завершается успешно (строка 62); можно было написать ее так, чтобы отмечать ошибки и указывать их в возвращаемом значении main(). (Механизм завершения процесса и значение различных кодов завершения обсуждаются в разделе 9.1.5.1 «Определение статуса завершения процесса».)

Код, работающий с struct stat и функцией fstat() (строки 31–36 и 50–56), без сомнения, непрозрачен, поскольку мы еще не рассматривали эти функции и не будем рассматривать до следующей главы (Но обратите внимание на использование fileno() в строке 50 для получения нижележащего дескриптора файла, связанного с переменными FILE*.) Идея в основе этого кода заключается в том, чтобы убедиться, что входной и выходной файлы не совпадают. Это предназначено для предотвращения бесконечного роста файла, в случае подобной команды:

$ cat myfile >> myfile /* Добавить копию myfile к себе? */

И конечно же, проверка работает:

$ echo hi > myfile /* Создать файл */

$ v7cat myfile >> myfile /* Попытка добавить файл к себе */

cat: input myfile is output

Если вы попробуете это с ch04-cat, программа продолжит работу, и myfile будет расти до тех пор, пока вы не прервете ее. GNU версия cat осуществляет эту проверку. Обратите внимание, что что-то вроде этого выходит за рамки контроля cat:

$ v7cat < myfile > myfile

cat: input - is output

$ ls -l myfile

-rw-r--r-- 1 arnold devel 0 Mar 24 14:17 myfile

В данном случае это слишком поздно, поскольку оболочка урезала файл myfile (посредством оператора >) еще до того, как cat получила возможность исследовать файл! В разделе 5.4.4.2 «Возвращаясь к V7 cat» мы объясним код с struct stat.

Как было описано ранее, open(), очевидно, открывает лишь существующие файлы. Данный раздел описывает, как создавать новые файлы. Есть две возможности: creat() и open() с дополнительными файлами. Первоначально creat() был единственным способом создания файла, но затем эта возможность была добавлена также и к open(). Оба механизма требуют указания начальных прав доступа к файлу.

4.6.1. Определение начальных прав доступа к файлу

Как пользователь GNU/Linux, вы знакомы с правами доступа к файлу, выдаваемыми командой 'ls -l': на чтение, запись и исполнение для каждого из владельца файла, группы и остальных. Различные сочетания часто выражаются в восьмеричной форме, в частности, для команд chmod и chmask. Например, права доступа к файлу -rw-r--r-- эквивалентны восьмеричному 0644, a -rwxr-xr-x эквивалентно восьмеричному 0755. (Ведущий 0 в нотации С означает восьмеричные значения.)

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

Таблица 4.5. Символические имена POSIX для режимов доступа к файлу

Следующий фрагмент показывает, как создать переменные, представляющие разрешения -rw-r--r-- и -rwxr-xr-x (0644 и 0755 соответственно):

mode_t rw_mode, rwx_mode;

rw_mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH; /* 0644 */

rwx_mode = S_IRWXU | S_IRGRP | S_IXGRP | S_IROTH | S_IXOTH; /* 0755 */

Более старый код использовал S_IREAD, S_IWRITE и S_IEXEC вместе со сдвигом битов для получения того же результата:

mode_t rw_mode, rwx_mode;

rw_mode = (S_IREAD|S_IWRITE) | (S_IREAD >> 3) | (S_IREAD >> 6); /* 0644 */

rwx_mode = (S_IREAD|S_IWRITE|S_IEXEC) |

 ((S_IREAD|S_IEXEC) >> 3) | ((S_IREAD|S_IEXEC) >> 6); /* 0755 */

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

При изменении прав доступа к файлу для использования доступны биты дополнительных разрешений, показанные в табл. 4.6, но они не должны использоваться при первоначальном создании файла. Возможность включения этих битов широко варьирует между операционными системами. Лучше всего не пробовать; вместо этого следует изменить права доступа к файлу явным образом после его создания. (Изменение прав доступа описано в разделе 5.5.2 «Изменение прав доступа: chmod() и fchmod()». Значения этих битов обсуждаются в главе 11 «Права доступа и идентификаторы пользователя и группы».)

Таблица 4.6. Дополнительные символические имена POSIX для режимов доступа к файлам

Когда стандартные утилиты создают файлы, они по умолчанию используют права доступа -rw-rw-rw- (или 0666). Поскольку большинство пользователей предпочитают избегать файлов, в которые может записывать кто угодно, каждый процесс имеет при себе umask. umask является набором битов допуска, указывающим те биты, которые никогда не должны устанавливаться при создании новых файлов, (umask не используется при изменении прав доступа.) Концептуально осуществляется операция

действительные_права = (затребованные_права & (~umask));

umask обычно устанавливается с помощью команды umask в $НОМЕ/.profile, когда вы входите в систему. Из программы С она устанавливается с помощью системного вызова umask().

#include /* POSIX */

#include mode_t umask(mode_t mask);

Возвращается старое значение umask. Поэтому для определения текущей маски нужно установить новое значение, а затем восстановить старое (или изменить его при необходимости):

mode_t mask = umask(0); /* получить текущую маску */

(void)umask(mask); /* восстановить ее */

Вот пример работы umask на уровне оболочки:

$ umask /* Показать текущую маску */

0022

$ touch newfile /* Создать файл */

$ ls -l newfile /* Показать права доступа нового файла */

-rw-r--r-- 1 arnold devel 0 Mar 24 15:43 newfile

$ umask 0 /* Установить пустую маску */

$ touch newfile2 /* Создать второй файл */

$ ls -l newfile2 /* Показать права доступа нового файла */

-rw-rw-rw- 1 arnold devel 0 Mar 24 15:44 newfile2

4.6.2. Создание файлов с помощью

creat()

Системный вызов creat() создает новые файлы. Он объявлен следующим образом:

#include /* POSIX */

#include

#include

int creat(const char *pathname, mode_t mode);

Аргумент mode представляет права доступа к новому файлу (как обсуждалось в предыдущем разделе). Создается файл с именем pathname.с данными правами доступа, модифицированными с использованием umask. Он открыт (только) для чтения, а возвращаемое значение является дескриптором нового файла или -1, если была проблема. В последнем случае errno указывает ошибку. Если файл уже существует, он будет при открытии урезан.

Во всех остальных отношениях дескрипторы файлов, возвращаемые creat(), являются теми же самыми, которые возвращаются open(); они используются для записи и позиционирования и должны закрываться при помощи close():

int fd, count;

/* Проверка ошибок для краткости опущена */

fd = creat("/some/new/file", 0666);

count = write(fd, "some data\n", 10);

(void)close(fd);

4.6.3. Возвращаясь к open()

Вы можете вспомнить объявление для open():

int open(const char *pathname, int flags, mode_t mode);

Ранее мы сказали, что при открытии файла для простого ввода/вывода мы можем игнорировать аргумент mode. Хотя, посмотрев на creat(), вы, возможно, догадались, что open() также может использоваться для создания файлов и что в этом случае используется аргумент mode. Это в самом деле так.

Помимо флагов O_RDONLY, O_WRONLY и O_RDWR, при вызове open() могут добавляться с использованием поразрядного OR дополнительные флаги. Стандарт POSIX предоставляет ряд этих дополнительных флагов. В табл. 4.7 представлены флаги, которые используются для большинства обычных приложений.

Таблица 4.7. Дополнительные флаги POSIX для open()

Если даны O_APPEND и O_TRUNC, можно представить, как оболочка могла бы открывать или создавать файлы, соответствующие операторам > и >>. Например:

int fd;

extern char *filename;

mode_t mode = S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH; /* 0666 */

fd = open(filename, O_CREAT | O_WRONLY | O_TRUNC, mode); /* для > */

fd = open(filename, O_CREAT | O_WRONLY | O_APPEND, mode); /* для >> */

Обратите внимание, что флаг O_EXCL здесь не используется, поскольку как для >, так и для >> не является ошибкой существование файла. Запомните также, что система применяет к запрошенным правам доступа umask.

Также легко видеть, что, по крайней мере концептуально, creat() можно было бы легко написать следующим образом:

int creat(const char *path, mode_t mode) {

 return open(path, O_CREAT | O_WRONLY | O_TRUNC, mode);

}

ЗАМЕЧАНИЕ . Если файл открыт с флагом O_APPEND , все данные будут записаны в конец файла, даже если текущее смещение было восстановлено с помощью lseek() .

Современные системы предоставляют дополнительные флаги с более специализированным назначением. Они кратко описаны в табл. 4.8.

Таблица 4.8. Дополнительные расширенные флаги POSIX для open()

Флаги O_DSYNC, O_RSYNC и O_SYNC требуют некоторых пояснений. Системы Unix (включая Linux) содержат внутренний кэш дисковых блоков, который называется буферным кэшем (buffer cache). Когда возвращается системный вызов write(), данные, переданные операционной системе, были скопированы в буфер в буферном кэше. Они необязательно были записаны на диск.

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

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

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

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

Флаг O_DSYNC гарантирует целостность данных; данные и любая другая информация, которую операционная система должна найти, записываются на диск до возвращения write(). Однако, вспомогательные данные, такие, как время модификации или доступа к файлу, могут быть не записаны на диск. Флаг O_SYNC требует, чтобы эти данные также были записаны на диск до возвращения write(). (Здесь тоже нет бесплатного обеда; синхронные записи могут серьезно повлиять на производительность программы, заметно ее снизив.)

Флаг O_RSYNC предназначен для чтения данных: если read() находит данные в буферном кэше, которые были назначены для записи на диск, функция не вернет эти данные до тех пор, пока они не будут записаны. Два других флага влияют на это: в частности, O_SYNC заставит read() ждать, пока не будут также записаны и вспомогательные данные.

ЗАМЕЧАНИЕ . Что касается ядра версии 2.4, Linux рассматривает все три флага одинаково со значением флага O_SYNC . Более того, Linux определяет дополнительные флаги, которые специфичны для Linux и предназначены для специального использования. Дополнительные подробности см. в справочной странице GNU/Linux для open (2).

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

5.1.1. Определения

Рис. Copyright 1997-2004 © J.D. «Illiad» Frazer. Использовано по разрешению, http://www.userfriendly.org

Мы начнем обсуждение с определения нескольких терминов.

Раздел (partition)

Единица физического хранилища. Физические разделы обычно являются либо частями диска, либо целым диском. Современные системы дают возможность создавать из нескольких физических логические разделы.

Файловая система (filesystem)

Раздел (физический или логический), содержащий данные файла и служебные данные (metadata), информацию о файлах (в противоположность содержимому файла, которое является информацией в файле). Такие служебные данные включают владельца файла, права доступа, размер и т.д., а также информацию, использующуюся операционной системой при поиске содержимого файла. Файловые системы размещаются «в» разделах (соотношение одни к одному) посредством записи в них стандартной информации. Это осуществляется программой уровня пользователя, такой, как mke2fs в GNU/Linux или newfs в Unix. (Команда Unix mkfs создает разделы, но ее трудно использовать, непосредственно, newfs вызывает ее с нужными параметрами. Если ваша система является системой Unix, подробности см. в справочных страницах для newfs(8) и mkfs(8).)

Большей частью GNU/Linux и Unix скрывают наличие файловых систем и разделов. (Дополнительные подробности приведены в разделе 8.1 «Монтирование и демонтирование файловых систем».) Доступ ко всему осуществляется через пути, безотносительно к тому, на каком диске расположен файл. (Сравните это с почти любой коммерческой операционной системой, такой, как OpenVMS, или с поведением по умолчанию любой системы Microsoft.)

Индекс (inode)

Сокращение от 'index node' (индексный узел), первоначально сокращалось 'i-node', а теперь пишется 'inode'. Небольшой блок информации, содержащий все сведения о файле, за исключением имени файла. Число индексов и, следовательно, число уникальных файлов в файловой системе, устанавливается и делается постоянным при создании файловой системы. Команда 'df -i' может показать, сколько имеется индексов и сколько из них используется.

Устройство (device)

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

Каталог (directory)

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

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

Рис. 5.1. Концептуальное представление индексов и блоков данных

На рисунке показаны все блоки индексов перед разделом и блоки данных после них. Ранние файловые системы Unix были организованы именно таким способом. Однако, хотя все современные системы до сих пор содержат индексы и блоки данных, их организация для повышения эффективности и устойчивости была изменена. Детали меняются от системы к системе, и даже в рамках систем GNU/Linux имеется множество разновидностей файловых систем, но концепция остается той же самой.

5.1.2. Содержимое каталога

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

Рис. 5.2. Концептуальное содержание каталога

На ранних Unix-системах были двухбайтные номера индексов, а имена файлов — до 14 байтов. Вот полное содержание файла V7 /usr/include/sys/dir.h:

#ifndef DIRSIZ

#define DIRSIZ 14

#endif

struct direct {

 ino_t d_ino;

 char d_name[DIRSIZ];

};

ino_t определен в V7 как 'typedef unsigned int into_t;'. Поскольку на PDP-11 int является 16-разрядным, таким же является и ino_t. Такая организация упрощала непосредственное чтение каталогов; поскольку размер элемента был фиксирован, код был простым. (Единственно, за чем нужно было следить, это то, что полное 14-символьное d_name не завершалось символом NUL.)

Управление содержанием каталога для системы также было простым. Когда файл удалялся из каталога, система заменяла номер индекса двоичным нулем, указывая, что элемент каталога не используется. Новые файлы могли потом использовать пустой элемент повторно. Это помогало поддерживать размер самих файлов каталогов в приемлемых рамках. (По соглашению, номер индекса 1 не используется; первым используемым индексом всегда является 2. Дополнительные сведения приведены в разделе 8.1 «Монтирование и демонтирование файловых систем».)

Современные системы предоставляют длинные имена файлов. Каждый элемент каталога имеет различную длину, с обычным ограничением для компонента имени файла каталога в 255 байтов. Далее мы увидим, как читать на современных системах содержимое каталога. Также в современных системах номера индексов 32 (или даже 64!) разрядные.

5.1.3. Прямые ссылки

5.1.4. Переименование файлов

При данном способе отображения элементами каталога имен на номера индексов, переименование файла концептуально очень просто:

1. Если новое имя файла обозначает существующий файл, сначала удалить этот файл.

2. Создать новую ссылку на файл через новое имя.

3. Удалить старое имя (ссылку) для файла. (Удаление имен обсуждается в следующем разделе.)

Ранние версии команды mv работали таким способом. Однако, при таком способе переименование файла не является атомарным; т.е. оно не осуществляется посредством одной непрерываемой операции. И на сильно загруженной системе злонамеренный пользователь мог бы воспользоваться условиями состояния гонки, разрушая операцию переименования и подменяя оригинальный файл другим.

По этой причине 4.2 BSD ввело системный вызов rename():

#include /* ISO С */

int rename(const char *oldpath, const char *newpath);

На системах Linux операция переименования является атомарной; справочная страница утверждает:

Если newpath уже существует, он будет атомарно замещен .., таким образом, что при попытке другого процесса получить доступ к newpath он никогда не обнаружит его отсутствующим.

Если newpath существует, но по какой-либо причине операция завершается неудачей, rename гарантирует, что экземпляр newpath останется на месте. Однако, в ходе переписывания возможно будет окно, в котором как oldpath , так и newpath ссылаются на переименовываемый файл.

Как и в случае с другими системными вызовами, возвращенный 0 означает успех, а (-1) означает ошибку.

5.1.5. Удаление файла

5.1.6. Символические ссылки

Мы начали главу с обсуждения разделов, файловых систем и индексов. Мы также увидели, что элементы каталога связывают имена с номерами индексов. Поскольку элементы каталога не содержат другой информации, прямые ссылки ограничены файлами внутри одной и той же файловой системы. Это должно быть; нет способа отличить индекс 2341 одной файловой системы от индекса 2341 другой файловой системы. Вот что случится, если мы попытаемся это сделать:

$  mount /* Показать использующиеся файловые системы */

/dev/hda2 on / type ext3 (rw)

/dev/hda5 on /d type ext3 (rw)

...

$ ls -li /tmp/message /* Предыдущий пример был в файловой системе / */

228786 -rw-r--r-- 2 arnold devel 19 May 4 15:51 /tmp/message

$ cat /tmp/message

Hi, how ya doin' ?

$ /bin/pwd /* Текущий каталог в другой файловой системе */

/d/home/arnold

$ ln /tmp/message . /* Попытка создать ссылку */

ln: creating hard link './message' to '/tmp/message': Invalid cross-device link

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

Чтобы обойти это ограничение, 4.2 BSD ввело символические ссылки (symbolic links, называемые также soft links). Символическая ссылка является особой разновидностью файла (также, как особой разновидностью файла является каталог). Содержимое этого файла представляет собой путь к файлу, на который данный файл «указывает». Все современные Unix-системы, включая Linux, предусматривают символические ссылки; конечно, они теперь являются частью POSIX.

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

При обработке имени файла система отмечает символические ссылки и осуществляет требуемые действия в файле или каталоге, который указан. Символические ссылки создаются с помощью опции -s команды ln:

$ /bin/pwd /* Где мы находимся */

/d/home/arnold /* В другой файловой системе */

$ ln -s /tmp/message ./hello /* Создать символическую ссылку */

$ cat hello /* Использовать ее */

Hi, how ya doin' ?

$ ls -l hello /* Отобразить информацию о ней */

lrwxrwxrwx 1 arnold devel 12 May 4 16:41 hello -> /tmp/message

Файл, на который указывает ссылка, необязательно должен существовать. Система обнаруживает это во время исполнения и действует соответствующим образом:

$ rm /tmp/message /* Удалить указываемый файл */

$ cat ./hello /* Попытка использования через символическую ссылку */

cat: ./hello: No such file or directory

$ echo hi again > hello /* Создать новое содержание файла */

$ ls -l /tmp/message /* Показать информацию об указываемом файле */

-rw-r--r-- 1 arnold devel 9 May 4 16:45 /tmp/message

$ cat /tmp/message /* ...и содержание */

hi again

Символические ссылки создаются с помощью системного вызова symlink():

#include /* POSIX */

int symlink(const char *oldpath, const char *newpath);

Аргумент oldpath содержит указываемый файл или каталог, a newpath является именем создаваемой символической ссылки. При успехе возвращается 0, а при ошибке (-1), возможные значения errno см. в справочной странице для symlink(2). У символических ссылок есть свои недостатки:

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

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

• Они могут создать «циклы». Рассмотрите следующее:

$ rm -f a b /* Убедиться, что 'a' и 'b' не существуют */

$ ln -s a b /* Создать ссылку старого файла 'a' на новый 'b' */

$ ln -s b a /* Создать ссылку старого файла 'b' на новый 'a' */

$ cat а /* Что случилось? */

cat: a: Too many levels of symbolic links

Ядро должно быть способно определить такой случай и выдать сообщение об ошибке.

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

В оригинальных системах Unix чтение содержимого каталогов было просто. Программа открывала каталог с помощью open() и непосредственно читала двоичные структуры struct direct, по 16 байтов за раз. Следующий фрагмент кода из программы V7 rmdir, строки 60–74. Он показывает проверку на пустоту каталога.

60 if ((fd = open(name, 0)) < 0) {

61  fprintf(stderr, "rmdir: %s unreadable\n", name);

62  ++Errors;

63  return;

64 }

65 while (read(fd, (char*)&dir, sizeof dir) == sizeof dir) {

66  if (dir.d_ino == 0) continue;

67  if (!strcmp(dir.d_name, ".") || !strcmp(dir.d_name, ".."))

68   continue;

69  fprintf(stderr, "rmdir: %s not empty\n", name);

70  ++Errors;

71  close(fd);

72  return;

73 }

74 close(fd);

В строке 60 каталог открывается для чтения (второй аргумент равен 0, что означает O_RDONLY). В строке 65 читается struct direct. В строке 66 проверяется, не является ли элемент каталога пустым, т. е. с номером индекса 0. Строки 67 и 68 проверяют на наличие '.' и '..'. По достижении строки 69 мы знаем, что было встречено какое-то другое имя файла, следовательно, этот каталог не пустой.

(Тест '!strcmp(s1, s2)' является более короткой формой 'strcmp(s1, s2) == 0', т.е. проверкой совпадения строк. Стоит заметить, что мы рассматриваем '!strcmp(s1, s2)' как плохой стиль. Как сказал однажды Генри Спенсер (Henry Spencer), «strcmp() это не boolean!».)

Когда 4.2 BSD представило новый формат файловой системы, который допускал длинные имена файлов и обеспечивал лучшую производительность, были также представлены несколько новых функций для абстрагирования чтения каталогов. Этот набор функций можно использовать независимо от того, какова лежащая в основе файловая система и как организованы каталоги. Основная ее часть стандартизована POSIX, а программы, использующие ее, переносимы между системами GNU/Linux и Unix.

5.3.1. Базовое чтение каталогов

5.3.2. Функции размещения каталогов BSD

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

#include /* XSI */

/* Предупреждение: POSIX XSI использует для обеих функций long, а не off_t */

off_t telldir(DIR *dir);              /* Вернуть текущее положение */

void seekdir(DIR *dir, off_t offset); /* Переместиться в данное положение */

Эти процедуры подобны функциям ftell() и fseek() и . Они возвращают текущее положение в каталоге и устанавливают текущее положение в ранее полученное значение соответственно.

Эти процедуры включены в часть XSI стандарта POSIX, поскольку они имеют смысл лишь для каталогов, которые реализованы с линейным хранением элементов каталога

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

Чтение каталога для получения имен файлов лишь половина дела. Получив имя файла, нужно знать, как получить остальную информацию, связанную с файлом, такую, как тип файла, права доступа к нему, владельца и т.д.

5.4.1. Типы файлов Linux

Linux (и Unix) поддерживает следующие различные типы файлов:

Обычные файлы

Как предполагает имя, данный тип используется для данных, исполняемых программ и всего прочего, что вам может понравиться. В листинге 'ls -l' они обозначаются в виде первого символа '-' поля прав доступа (режима).

Каталоги

Специальные файлы для связывания имен файлов с индексами. В листинге 'ls -l' они обозначаются первым символом d поля прав доступа.

Символические ссылки

Как описано ранее в главе. В листинге 'ls -l' обозначаются первым символом l (буква «эль», не цифра 1) поля прав доступа.

Устройства

Файлы, представляющие как физические аппаратные устройства, так и программные псевдоустройства. Есть две разновидности:

Блочные устройства

Устройства, ввод/вывод которых осуществляется порциями некоторого фиксированного размера физической записи, такие, как дисковые и ленточные приводы. Доступ к таким устройствам осуществляется через буферный кэш ядра. В листинге 'ls -l' они обозначаются первым символом b поля прав доступа.

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

Известны также как непосредственные (raw) устройства. Первоначально символьными устройствами были те, в которых ввод/вывод осуществлялся по несколько байтов за раз, как в терминалах. Однако, символьное устройство используется также для непосредственного ввода/вывода на блочные устройства, такие, как ленты и диски, минуя буферный кэш. В листинге 'ls -l' они отображаются первым символом с поля прав доступа.

Именованные каналы (named pipes)

Известны также файлы FIFO («first-in first-out» — «первым вошел, первым обслужен»). Эти специальные файлы действуют подобно конвейерам (pipes); данные, записанные в них одной программой, могут быть прочитаны другой; данные не записываются на диск и не считываются с диска. FIFO создаются с помощью команды mkfifo; они обсуждаются в разделе 9.3.2 «FIFO». В листинге 'ls -l' они отображаются первым символом p поля прав доступа.

Сокеты

Сходные по назначению с именованными каналами, они управляются системными вызовами межпроцессных взаимодействий (IPC) сокетов, и мы не будем в данной книге иметь с ними дело в других отношениях. В листинге 'ls -l' они отображаются первым символом s поля прав доступа.

5.4.2. Получение информации о файле

Три системных вызова возвращают информацию о файлах:

#include /* POSIX */

#include

#include

int stat(const char *file_name, struct stat *buf);

int fstat(int filedes, struct stat *buf);

int lstat(const char *file_name, struct stat *buf);

Функция stat() получает имя файла с путем и возвращает сведения о данном файле. Она следует по символическим ссылкам; т. е. при применении к символической ссылке stat() возвращает информацию об указываемом файле, а не о самой ссылке. В тех случаях, когда вам нужно знать, является ли файл символической ссылкой, используйте вместо нее функцию lstat(); последняя не следует по символическим ссылкам.

Функция fstat() получает сведения об уже открытом файле. Это особенно полезно для дескрипторов файлов 0, 1 и 2 (стандартных ввода, вывода и ошибки), которые уже открыты при запуске процесса. Однако, она может использоваться с любым открытым файлом. (Дескриптор открытого файла никогда не будет относиться к символической ссылке; убедитесь, что понимаете, почему.)

Значение, переданное в качестве второго параметра, должно быть адресом struct stat, объявленной в . Как в случае с struct dirent, struct stat содержит по крайней мере следующие члены:

struct stat {

 ...

 dev_t st_dev;         /* устройство */

 ino_t st_ino;         /* индекс */

 mode_t st_mode;       /* тип и защита */

 nlink_t st_nlink;     /* число прямых (hard) ссылок */

 uid_t st_uid;         /* ID владельца */

 gid_t st_gid;         /* ID группы */

 dev_t st_rdev;        /* тип устройства (блочное или символьное) */

 off_t st_size;        /* общий размер в байтах */

 blksize_t st_blksize; /* размер блока для ввода/вывода файл, с-мы */

 blkcnt_t st_blocks;   /* число выделенных блоков */

 time_t st_atime;      /* время последнего доступа */

 time_t st_mtime;      /* время последнего изменения */

 time_t st_ctime;      /* время последнего изменения индекса */

 ...

};

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

st_dev

Устройство для монтируемой файловой системы. У каждой монтируемой файловой системы уникальное значение st_dev.

st_ino

Номер индекса файла в пределах файловой системы. Пара (st_dev, st_ino) уникально идентифицирует файл.

st_mode

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

st_nlink

Число прямых ссылок на файл (счетчик ссылок). Может равняться нулю, если файл был удален после открытия.

st_uid

UID файла (номер владельца).

st_gid

GID файла (номер группы).

st_rdev

Тип устройства, если файл является блочным или символьным устройством. st_rdev содержит закодированную информацию об устройстве. Вскоре мы увидим, как извлечь эту информацию. Это поле не имеет смысла, если файл не является блочным или символьным устройством.

st_size

Логический размер файла. Как упоминалось в разделе 4.5 «Произвольный доступ: перемещение внутри файла», файл может содержать в себе дыры, в этом случае размер может не отражать истинного значения занимаемого им места.

st_blksize

«Размер блока» файла. Представляет предпочтительный размер блока данных для ввода/вывода данных в или из файла. Почти всегда превышает размер физического сектора диска. У более старых систем Unix нет этого поля (или поля st_blocks) в struct stat. Для файловых систем Linux ext2 и ext3 это значение составляет 4096.

st_blocks

Число «блоков», используемых файлом. В Linux это значение представлено в единицах 512-байтных блоков. На других системах размер блока может быть различным, проверьте свою локальную страницу справки для stat(2). (Это число происходит от константы DEV_BSIZE в . Эта константа не стандартизована, но довольно широко используется в системах Unix.)

Число блоков может быть больше, чем 'st_size / 512'; кроме блоков данных, файловая система может использовать дополнительные блоки для хранения размещений блоков данных. Это особенно необходимо для больших файлов.

st_atime

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

st_mtime

Время модификации файла; т е. когда в последний раз данные файла записывались или урезались.

st_ctime

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

ЗАМЕЧАНИЕ . Поле st_ctime не является «временем создания»! В системе Linux или Unix нет такой вещи. Часть более ранней документации называла поле st_ctime временем создания. Это была вводящая в заблуждение попытка упростить представление служебных данных файла

Тип time_t, использованный для полей st_atime, st_mtime и st_ctime, представляет дату и время. Эти относящиеся ко времени значения иногда называют временными метками (timestamps). Обсуждение того, как использовать значение time_t, отложено до раздела 6.1 «Время и даты». Подобным же образом типы uid_t и gid_t представляют номера владельца и группы, которые обсуждаются в разделе 6.3 «Имена пользователя и группы». Большинство других типов не представляют широкого интереса.

5.4.3. Только Linux: указание файлового времени повышенной точности

Ядра Linux 2.6 и более поздние предоставляют в struct stat три дополнительных поля. Они предусматривают точность файлового времени до наносекунд:

st_atime_nsec  Наносекундная компонента времени доступа к файлу.

st_mtime_nsec  Наносекундная компонента времени изменения файла

st_ctime_nsec  Наносекундная компонента времени изменения служебных данных файла.

Некоторые другие системы также предоставляют такие поля с повышенной точностью времени, но имена соответствующих членов структуры struct stat не стандартизованы, что затрудняет написание переносимого кода, использующего эти времена. (Связанные с этим расширенные системные вызовы см. в разделе 14.3.2 «Файловое время в микросекундах: utimes()».)

5.4.4. Определение типа файла

 

Вспомните, что в поле st_mode закодированы как тип файла, так и права доступа к нему. определяет ряд макросов, которые определяют тип файла. В частности, эти макросы возвращают true или false при использовании с полем st_mode. У каждого описанного ранее типа файла есть свой макрос. Предположим, выполняется следующий код:

struct stat stbuf;

char filename[PATH_МАХ]; /* PATH_MAX из */

/* ... поместить имя файла в filename ... */

if (stat(filename, &stbuf) < 0) {

 /* обработать ошибку */

}

Когда система заполнила stbuf, можно вызывать следующие макросы, причем в качестве аргумента передается stbuf.st_mode:

S_ISREG(stbuf.st_mode)

Возвращает true, если filename является обычным файлом.

S_ISDIR(stbuf.st_mode)

Возвращает true, если filename является каталогом.

S_ISCHR(stbuf.st_mode)

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

S_ISBLK(stbuf.st_mode)

Возвращает true, если filename является блочным устройством.

S_ISFIFO(stbuf.st_mode)

Возвращает true, если filename является FIFO.

S_ISLNK(stbuf.st_mode)

Возвращает true, если filename является символической ссылкой. (Это может никогда не вернуть true, если вместо lstat() использовались stat() или fstat().)

S_ISSOCK(stbuf.st_mode)

Возвращает true, если filename является сокетом.

ЗАМЕЧАНИЕ . В GNU/Linux эти макросы возвращают 1 для true и 0 для false . Однако, на других системах возможно, что они будут возвращать для true вместо 1 произвольное неотрицательное число. (POSIX определяет лишь ненулевое значение в противоположность нулевому). Поэтому всегда следует использовать эти макросы как автономные тесты вместо проверки возвращаемого значения.

/* Корректное использование */

if (S_ISREG(stbuf.st_mode)) ...

/* Heкорректное использование */

if (S_ISREG(stbuf.st_mode) ==1) ...

Наряду с макросами предоставляет два набора битовых масок. Один набор для проверки прав доступа, а другой - для проверки типа файла. Мы видели маски прав доступа в разделе 4.6 «Создание файлов», когда обсуждали тип mode_t и значения для open() и creat(). Битовые маски, их числовые значения для GNU/Linux и смысл приведены в табл. 5.2.

Таблица 5.2. Битовые маски POSIX для типов файлов и прав доступа в

Маска	Значение	Комментарий
S_IFMT	0170000	Маска для битовых полей типа файла
S_IFSOCK	0140000	Сокет.
S_IFLNK	0120000	Символическая ссылка
S_IFREG	0100000	Обычный файл.
S_IFBLK	0060000	Блочное устройство.
S_IFDIR	0040000	Каталог.
S_IFCHR	0020000	Символьное устройство.
S_IFIFO	0010000	FIFO.
S_ISUID	0004000	Бит setuid.
S_ISGID	0002000	Бит setgid
S_ISVTX	0001000	«Липкий» (sticky) бит.
S_IRWXU	0000700	Маска для прав доступа владельца.
S_IRUSR	0000400	Доступ на чтение для владельца.
S_IWUSR	0000200	Доступ на запись для владельца.
S_IXUSR	0000100	Доступ на исполнение для владельца.
S_IRWXG	0000070	Маска для прав доступа группы.
S_IRGRP	0000040	Доступ на чтение для группы.
S_IWGRP	0000020	Доступ на запись для группы.
S_IXGRP	0000010	Доступ на исполнение для группы.
S_IRWXO	0000007	Маска для прав доступа остальных.
S_IROTH	0000004	Доступ на чтение для остальных.
S_IWOTH	0000002	Доступ на запись для остальных.
S_IXOTH	0000001	Доступ на исполнение для остальных.

Некоторые из этих масок служат цели изолирования различных наборов битов, закодированных в поле st_mode:

• S_IFMT представляет биты 12–15, которыми закодированы различные типы файлов.

• S_IRWXU представляет биты 6–8, являющиеся правами доступа владельца (на чтение, запись, исполнение для User).

• S_IRWXG представляет биты 3–5, являющиеся правами доступа группы (на чтение, запись, исполнение для Group).

• S_IRWXO представляет биты 0–2, являющиеся правами доступа для «остальных» (на чтение, запись, исполнение для Other).

Биты прав доступа и типа файла графически изображены на рис. 5.3.

Рис. 5.3. Биты прав доступа и типа файлов

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

Стандарт POSIX явным образом констатирует; что в будущем не будут стандартизированы новые битовые маски и что тесты для любых дополнительных разновидностей типов файлов, которые могут быть добавлены, будут доступны лишь в виде макросов S_IS xxx () .

5.4.5. Работа с символическими ссылками

В общем, символические ссылки ведут себя подобно прямым ссылкам; файловые операции, такие, как open() и stat(), применяются к указываемому файлу вместо самой символической ссылки. Однако, бывают моменты, когда в самом деле необходимо работать с символической ссылкой вместо файла, на которую она указывает.

По этой причине существует системный вызов lstat(). Он действует точно также, как stat(), но если проверяемый файл окажется символической ссылкой, возвращаемые сведения относятся к символической ссылке, а не к указываемому файлу. А именно:

• S_ISLNK(sbuf.st_mode) будет true.

• sbuf.st_size содержит число байтов в имени указываемого файла.

Мы уже видели, что системный вызов symlink() создает символическую ссылку. Но если дана существующая символическая ссылка, как можно получить имя файла, на которую она указывает? (Очевидно, ls может получить это имя; поэтому мы должны быть способны это сделать.)

Открывание ссылки с помощью open() для чтения ее с использованием read() не будет работать, open() следует по ссылке на указываемый файл. Таким образом, символические ссылки сделали необходимым дополнительный системный вызов, который называется readlink():

#include /* POSIX */

int readlink(const char *path, char *buf, size_t bufsiz);

readlink() помещает содержимое символической ссылки, на имя которой указывает path, в буфер, на который указывает buf. Копируется не более bufsiz символов. Возвращаемое значение равно числу символов, помещенных в buf, либо -1, если возникла ошибка, readlink() не вставляет завершающий нулевой байт.

Обратите внимание, что если буфер, переданный readlink(), слишком маленький, информация будет потеряна; полное имя указываемого файла будет недоступно. Чтобы использовать readlink() должным образом, вы должны делать следующее:

1. Используйте lstat(), чтобы убедиться, что это символическая ссылка.

2. Убедитесь, что ваш буфер для содержимого символической ссылки составляет по крайней мере 'sbuf.st_size + 1' байтов; '+ 1' нужно для завершающего нулевого байта, чтобы сделать буфер годной к употреблению строкой С.

3. Вызовите readlink(). Не мешает проверить, что возвращенное значение равно sbuf.st_size.

4. Добавьте '\0' к байту после содержимого ссылки, чтобы превратить его в строку С. Код для всего этого мог бы выглядеть примерно так:

/* Проверка ошибок для краткости опущена */

int count;

char linkfile[PATH_MAX], realfile[PATH_MAX]; /* PATH_MAX в */

strut stat sbuf;

/* ...поместить в linkfile путь к нужной символической ссылке... */

lstat(linkfile, &sbuf); /* Получить сведения от stat */

if (!S_ISLNK(sbuf.st_mode)) /* Проверить, что это ссылка */

 /* не символическая ссылка, обработать это */

if (sbuf.st_size + 1 > PATH_МАХ) /* Проверить размер буфера */

 /* обработать проблемы с размером буфера */

count = readlink(linkfile, realfile, PATH_MAX);

/* Прочесть ссылку */

if (count != sbuf.st_size)

 /* происходит что-то странное, обработать это */

realfile(count) = '\0'; /* Составить строку С */

Данный пример для простоты представления использует буферы фиксированного размера. Реальный код мог бы использовать для выделения буфера нужного размера malloc(), поскольку массивы фиксированного размера могли бы оказаться слишком маленькими. Файл lib/xreadlink.c в GNU Coreutils делает именно это. Он читает содержимое символической ссылки в память, выделенную malloc(). Мы покажем здесь саму функцию, большая часть файла представляет собой стереотипные определения. Номера строк относятся к началу файла:

55 /* Вызвать readlink для получения значения ссылки FILENAME.

56 Вернуть указатель на завершенную NUL строку в выделенной malloc памяти.

57 При ошибке readlink вернуть NULL (использовать errno для диагноза).

58 При ошибке realloc или если значение ссылки больше SIZE_MAX,

59 выдать диагностику и выйти. */

60

61 char*

62 xreadlink(char const* filename)

63 {

64  /* Начальный размер буфера для ссылки. Степень 2 обнаруживает

65     арифметическое переполнение раньше, но не рекомендуется. */

66  size_t buf_size = 128;

67

68  while(1)

69  {

70   char *buffer = xmalloc(buf_size);

71   ssize_t link_length = readlink(filename, buffer, buf_size);

72

73   if (link_length < 0)

74   {

75    int saved_errno = errno;

76    free(buffer);

77    errno = saved_errno;

78    return NULL;

79   }

80

81   if ((size_t)link_length < buf_size)

82   {

83    buffer[link_length] = 0;

84    return buffer;

85   }

86

87   free(buffer);

88   buf_size *= 2;

89   if (SSIZE_MAX < buf_size || (SIZE_MAX / 2 < SSIZE_MAX && buf_size == 0))

90    xalloc_die();

91  }

92 }

Тело функции состоит из бесконечного цикла (строки 68–91), разрываемого в строке 84, которая возвращает выделенный буфер. Цикл начинается выделением первоначального буфера (строка 70) и чтения ссылки (строка 71). Строки 73–79 обрабатывают случай ошибки, сохраняя и восстанавливая errno таким образом, что она может корректно использоваться вызывающим кодом.

Строки 81–85 обрабатывают случай «успеха», при котором размер содержимого ссылки меньше размера буфера. В этом случае добавляется завершающий ноль (строка 83), а затем буфер возвращается, прерывая бесконечный цикл. Это гарантирует, что в буфер помещено все содержимое ссылки, поскольку у readlink() нет возможности сообщить о «недостаточном размере буфера».

Строки 87–88 освобождают буфер и удваивают размер буфера для следующей попытки в начале цикла. Строки 89–90 обрабатывают случай, при котором размер ссылки слишком велик: buf_size больше, чем SSIZE_MAX, или SSIZE_MAX больше, чем значение, которое может быть представлено в знаковом целом того же размера, который использовался для хранения SIZE_MAX, и buf_size обернулся в ноль. (Это маловероятные условия, но странные вещи все же случаются.) Если одно из этих условий верно, программа завершается с сообщением об ошибке. В противном случае функция возвращается в начало цикла, чтобы сделать еще одну попытку выделить буфер и прочесть ссылку.

Некоторое дополнительное разъяснение: условие 'SIZE_MAX / 2 < SSIZE_MAX' верно лишь на системах, в которых 'SIZE_MAX < 2 * SSIZE_MAX'; мы не знаем таких, но лишь на таких системах buf_size может обернуться в ноль. Поскольку на практике это условие не может быть истинным, компилятор может оптимизировать все выражение, включив следующую проверку 'buf_size == 0'. После прочтения этого кода вы можете спросить: «Почему не использовать lstat() для получения размера символической ссылки, не выделить буфер нужного размера с помощью malloc(), и все?» На это есть несколько причин.

• lstat() является системным вызовом — лучше избежать накладных расходов по его вызову, поскольку содержимое большинства символических ссылок поместится в первоначальный размер буфера в 128.

• Вызов lstat() создает условие состязания: ссылка может измениться между исполнением lstat() и readlink(), в любом случае вынуждая повторение.

• Некоторые системы не заполняют должным образом член st_size для символической ссылки. (Печально, но верно.) Сходным образом, как мы увидим в разделе 8.4.2 «Получение текущего каталога: getcwd()», Linux в /proc предоставляет специальные символические ссылки, у которых st_size равен нулю, но для которых readlink() возвращает действительное содержимое.

Наконец, буфер не слишком большой, xreadlink() использует free() и malloc() с большим размером вместо realloc(), чтобы избежать бесполезного копирования, которое делает realloc(). (Поэтому комментарий в строке 58 устарел, поскольку realloc() не используется; это исправлено в версии Coreutils после 5.0.)

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

5.5.1. Смена владельца файла:

chown()

,

fchown()

и

lchown()

Владелец и группа файла изменяются с помощью трех сходных системных вызовов.

#include /* POSIX */

#include

int chown(const char *path, uid_t owner, gid_t group);

int fchown(int fd, uid_t owner, gid_t group);

int lchown(const char *path, uid_t owner, gid_t group);

chown() работает с аргументом имени файла, fchown() работает с открытым файлом, а lchown() работает с символической ссылкой вместо файла, на который эта ссылка указывает. Во всех других отношениях эти три вызова работают идентично, возвращая 0 в случае успеха и -1 при ошибке.

Стоит заметить, что один системный вызов изменяет как владельца, так и группу файла. Чтобы изменить лишь владельца или лишь группу, передайте (-1) в качестве того идентификационного номера, который должен остаться без изменений.

Хотя вы могли бы подумать, что можно передать соответствующее значение из полученного заранее struct stat для файла или файлового дескриптора, этот метод больше подвержен ошибкам. Возникает условие состязания: между вызовами stat() и chown() владелец или группа могут измениться.

Вы могли бы поинтересоваться: «Зачем нужно изменять владельца символической ссылки? Права доступа и владение ей не имеют значения». Но что случится, если пользователь уходит, а все его файлы все еще нужны? Необходима возможность изменения владельца всех файлов этого лица на кого-то еще, включая символические ссылки.

Системы GNU/Linux обычно не позволяют рядовым пользователям (не root) изменять владельца («отдавать») своих файлов. Смена группы на одну из групп пользователя, конечно, разрешена. Ограничение в смене владельцев идет от BSD систем, у которых тоже есть этот запрет. Главная причина в том, что разрешение пользователям отдавать файлы может нарушить дисковый учет. Рассмотрите такой сценарий:

$ mkdir mywork /* Создать каталог */

$ chmod go-rwx mywork /* Установить права доступа drwx------ */

$ cd mywork /* Перейти в него */

$ myprogram > large_data_file /* Создать большой файл */

$ chmod ugo+rw large_data_file /* Установить доступ -rw-rw-rw- */

$ chown otherguy large_data_file /* Передать файл otherguy */

В этом примере large_data_file теперь принадлежит пользователю otherguy. Первоначальный пользователь может продолжать читать и записывать файл из-за его прав доступа. Но дисковое пространство, которое он занимает, будет записано на счет otherguy. Однако, поскольку он находится в каталоге, который принадлежит первому пользователю и к которому otherguy не может получить доступ, otherguy не имеет возможности удалить файл.

Некоторые системы System V разрешают пользователям передавать свои файлы. (При смене владельца соответствующие биты файлов setuid и setgid сбрасываются.) Это может быть особенной проблемой, когда файлы извлекаются из архива .tar или .cpio; извлеченные файлы имеют UID и GID, закодированный в архиве. На таких системах программы tar и cpio имеют опции, предотвращающие это, но важно знать, что поведение chown() действительно отличается на разных системах.

В разделе 6.3 «Имена пользователя и группы» мы увидим, как соотносить имена пользователя и группы с соответствующими числовыми значениями

5.5.2. Изменение прав доступа:

chmod()

и

fchmod()

Изменение прав доступа осуществляется с помощью одного из двух системных вызовов, chmod() и fchmod():

#include /* POSIX */

#include

int chmod(const char *path, mode_t mode);

int fchmod(int fildes, mode_t mode);

chmod() работает с аргументом имени файла, a fchmod() работает с открытым файлом. (В POSIX нет вызова lchmod(), поскольку система игнорирует установки прав доступа для символических ссылок. Хотя на некоторых системах такой вызов действительно есть). Как и для большинства других системных вызовов, они возвращают 0 в случае успеха и -1 при ошибке. Права доступа к файлу может изменить лишь владелец файла или root.

Значение mode создается таким же образом, как для open() и creat(), как обсуждалось в разделе 4.6 «Создание файлов». См. также табл. 5.2, в которой перечислены константы прав доступа.

Система не допустит установки бита setgid (S_ISGID), если группа файла не совпадает с ID действующей группы процесса или с одной из его дополнительных групп. (Мы пока не обсуждали подробно эти проблемы; см. раздел 11.1.1 «Реальные и действующие ID».) Разумеется, эта проверка не относится к root или коду, выполняющемуся как root.

5.5.3. Изменение временных отметок:

utime()

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

fchown()

и

fchmod()

для обеспечения безопасности

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

Однако, после открытия файла условие состязания больше не представляет проблему. Программа может использовать stat() с именем файла для получения информации о файле. Если получены сведения, которые ожидались, после открытия файла fstat() может проверить, что файл тот же самый (сравнив поля st_dev и st_ino структур struct stat «до» и «после»).

Когда программа знает, что файлы те же самые, владение или права доступа могут быть изменены с помощью fchown() или fchmod().

Эти системные вызовы, также как lchown(), сравнительно недавние; в старых системах Unix их не было, хотя в современных совместимых с POSIX системах они есть.

Соответствующих функций futime() или lutime() нет. В случае futime() это (очевидно) потому, что временные отметки не являются критическими для безопасности системы в том же отношении, что для владения и прав доступа, lutime() отсутствует потому, что временные отметки неуместны для символических ссылок.

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

На системах GNU/Linux и Unix значения time_t представляют «секунды с начала Эпохи». Эпоха представляет собой начало записываемого времени, которое относится к полночи 1 января 1970 г. по UTC. На большинстве систем time_t является long int С. Для 32-разрядных систем это означает, что time_t переполнится 19 января 2038 г. К тому времени, мы надеемся, тип time_t будет переопределен как по меньшей мере 64-разрядное значение.

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

Отдельный набор функций предоставляет доступ к текущему времени с разрешением, большим чем одна секунда. Функции работают с предоставлением двух различных значений, времени в виде секунд с начала Эпохи и числа микросекунд в текущей секунде. Эти функции описаны далее в разделе 14.3.1 «Время в микросекундах: gettimeofday()».

6.1.1. Получение текущего времени:

time()

и

difftime()

Системный вызов time() получает текущие дату и время; difftime() вычисляет разницу между двумя значениями time_t:

#include /* ISO С */

time_t time(time_t *t);

double difftime(time_t time1, time_t time0);

time() возвращает текущее время. Если параметр t не равен NULL, переменная, на которую указывает t, также заполняется значением текущего времени. Функция возвращает (time_t)(-1), если была ошибка, устанавливая errno.

Хотя ISO С не указывает, чем является значение time_t, POSIX определяет, что оно представляет время в секундах. Поэтому это предположение является обычным и переносимым. Например, чтобы посмотреть, что значение времени представляет отметку в прошлом шесть месяцев назад или позже, можно использовать код, подобный этому:

/* Для краткости проверка ошибок опущена */

time_t now, then, some_time;

time(&now); /* Получить текущее время */

then = now - (6L * 31 * 24 * 60 * 60); /* Примерно 6 месяцев назад */

/* ...установить какое-нибудь время, например, через stat()... */

if (some_time < then)

 /* более 6 месяцев назад */

else

 /* менее 6 месяцев назад */

Однако, поскольку переносимый код может потребоваться запустить на не-POSIX системах, существует функция difftime() для вычисления разницы между двумя значениями времени. Тот же самый тест с использованием difftime() можно было бы написать таким способом:

time_t now, some_value;

const double six_months = 6.0 * 31 * 24 * 60 * 60;

time(&now); /* Получить текущее время */

/* ...установить какое-нибудь время, например, через stat()... */

if (difftime(now, some_time) >= six_months)

 /* более 6 месяцев назад */

else

 /* менее 6 месяцев назад */

Возвращаемым типом difftime() является double, поскольку time_t может также содержать доли секунд. На системах POSIX он всегда представляет целые секунды.

В обоих предыдущих примерах обратите внимание на использование типизированных констант, чтобы форсировать выполнение вычислений с нужным математическим типом: 6L в первом случае для целых long, 6.0 во втором случае для чисел с плавающей точкой

6.1.2. Разложение времени:

gmtime()

и

localtime()

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

#include /* ISO С */

struct tm *gmtime(const time_t *timep);

struct tm *localtime(const time_t *timep);

gmtime() возвращает указатель на struct tm, которая представляет время UTC. localtime() возвращает указатель на struct tm, представляющий местное время, т.е. в расчет берутся текущий часовой пояс и переход на летнее время. На самом деле это «время для настенных часов», дата и время, которые были бы отображены на настенных или ручных часах. (Как это работает, обсуждается далее в разделе 6.1.5 «Получение сведений о часовом поясе».)

Обе функции возвращают указатель на struct tm, которая выглядит следующим образом:

struct tm {

 int tm_sec;   /* секунды */

 int tm_min;   /* минуты */

 int tm_hour;  /* часы */

 int tm_mday;  /* день месяца */

 int tm_mon;   /* месяц */

 int tm_year;  /* год */

 int tm_wday;  /* день недели */

 int tm_yday;  /* день в году */

 int tm_isdst; /* летнее время */

};

struct tm называют разложенным временем (broken-down time), поскольку значение time_t «разложено» на свои составные части. Составные части, их диапазоны и значения показаны в табл. 6.1.

Таблица 6.1. Поля структуры tm

Стандарт ISO С представляет большинство этих значений как «x после y». Например, tm_sec является числом «секунд после минуты», tm_mon «месяцев после января», tm_wday «дней недели после воскресенья» и т.д. Это помогает понять, почему все значения начинаются с 0. (Единственным исключением, достаточно логичным, является tm_mday, день месяца, имеющий диапазон 1–31.) Конечно, отсчет их с нуля также практичен; поскольку массивы С отсчитываются с нуля, использование этих значений в качестве индексов тривиально:

static const char *const days[] = { /* Массив имен дней */

 "Sunday", "Monday", "Tuesday", "Wednesday",

 "Thursday", "Friday", "Saturday",

};

time_t now;

struct tm *curtime;

time(&now); /* Получить текущее время */

curtime = gmtime(&now); /* Разложить его */

printf("Day of the week: %s\n", days[curtime->tm_wday]);

 /* Проиндексировать и вывести */

Как gmtime(), так и localtime() возвращают указатель на struct tm. Указатель указывает на static struct tm, содержащуюся в каждой процедуре, и похоже, что эти структуры struct tm переписываются каждый раз, когда вызываются процедуры. Поэтому хорошая мысль сделать копию возвращенной struct. Возвращаясь к предыдущему примеру.

static const char *const days[] = { /* Как ранее */ };

time_t now;

struct tm curtime; /* Структура, а не указатель */

time(&now); /* Получить текущее время */

curtime = *gmtime(&now); /* Разложить его и скопировать данные */

printf("Day of the week: %s\n", days[curtime.tm_wday]);

 /* Проиндексировать и напечатать, использовать . , а не -> */

Поле tm_isdst указывает, действует ли в настоящий момент летнее время (DST) Значение 0 означает, что DST не действует, положительное значение означает, что действует, а отрицательное значение — что информация о DST недоступна. (Стандарт С намеренно неконкретен, указывая лишь нулевое, положительное и отрицательное значения; это дает возможность большей свободы при реализации.)

6.1.3. Форматирование даты и времени

 

6.1.3.1. Простое форматирование времени:

asctime()

и

ctime()

Две первые стандартные процедуры, перечисленные ниже, выводят данные в фиксированном формате:

#include /* ISO С */

char *asctime(const struct tm *tm);

char *ctime(const time_t *timep);

Как и в случае с gmtime() и localtime(), asctime() и ctime() возвращают указатели на статические буфера, которые могут быть перезаписаны после каждого вызова. Более того, эти две процедуры возвращают строки в одном и том же формате. Они отличаются лишь видом принимаемых аргументов, asctime() и ctime() должны использоваться тогда, когда все, что вам нужно, это простые сведения о дате и времени.

#include

#include

int main(void) {

 time_t now;

 time(&now);

 printf("%s", ctime(& now));

}

После запуска эта программа выводит результат в виде: 'Thu May 22 15:44:21 2003'. Завершающий символ конца строки включен в результат. Точнее, возвращаемое значение указывает на массив из 26 символов, как показано на рис. 6.1.

Рис. 6.1. Возвращаемая функциями ctime() и asctime() строка

Значительная часть старого кода Unix полагается на тот факт, что значения в возвращенной строке имеют фиксированную позицию. При использовании этих функций помните, что они включают завершающий символ конца строки. Поэтому наш небольшой пример программы использует для printf() простую форматирующую строку "%s", а не "%s\n", как можно было бы ожидать.

ctime() устраняет необходимость шага вызова localtime(); в сущности, это эквивалентно

time_t now;

char *curtime;

time(&now);

curtime = asctime(localtime(&now));

6.1.4. Преобразование разложенного времени в

time_t

Получение от системы значений «секунд с начала Эпохи» просто; именно так даты и времена хранятся в индексах и возвращаются с помощью time() и stat(). Эти значения также легко оценивать на равенство или посредством < и > для простых тестов раньше/позже.

Однако, с датами, введенными людьми, не так легко работать. Например, многие версии команды touch позволяют предусмотреть дату и время, в которое touch должна установить время модификации или доступа к файлу (с помощью utime(), как было описано в разделе 5.5.3 «Изменение отметок времени: utime()»).

Преобразование даты, введенной человеком, в значение time_t трудно: надо принять во внимание високосные годы, учесть часовые пояса и т.д. Поэтому стандарт C89 ввел функцию mktime():

#include /* ISO С */

time_t mktime(struct tm *tm);

Для использования mktime() укажите в struct tm соответствующие значения — год, месяц, день и т.д. Если вы знаете, действовало ли для данной даты летнее время, установите соответствующим образом поле tm_isdst: 0 для «нет» и положительное значение для «да». В противном случае, используйте отрицательное значение для «не знаю». Поля tm_wday и tm_yday игнорируются.

mktime() предполагает, что struct tm представляет локальное время, не UTC. Она возвращает значение time_t, представляющее переданные дату и время, или (time_t)(-1), если данные дата/время не могут быть правильно представлены. После успешного возвращения все значения struct tm выверены на попадание в правильные диапазоны, a tm_wday и tm_yday также корректно установлены. Вот простой пример:

1  /* ch06-echodate.c --- демонстрирует mktime(). */

2

3  #include

4  #include

5

6  int main(void)

7  {

8   struct tm tm;

9   time_t then;

10

11  printf("Enter a Date/time as YYYY/MM/DD HH:MM:SS : ");

12  scanf("%d/%d/%d %d:%d:%d",

13   &tm.tm_year, &tm.tm_mon, &tm.tm_mday,

14   &tm.tm_hour, &tm.tm_min, &tm.tm_sec);

15

16  /* Проверка ошибок значений для краткости опущена. */

17  tm.tm_year -= 1900;

18  tm.tm_mon--;

19

20  tm.tm_isdst = -1; /* He знаю о летнем времени */

21

22  then = mktime(&tm);

23

24  printf("Got: %s", ctime(&then));

25  exit(0);

26 }

В строке 11 запрашиваются дата и время, а в строках 12–14 соответствующие значения считываются. (В коде изделия возвращаемые scanf() значения должны проверяться.) Строки 17 и 18 компенсируют различную базу для лет и месяцев соответственно. Строка 20 указывает, что мы не знаем, представляют ли данные дата и время летнее время. Строка 22 вызывает mktime(), а строка 24 выводит результат преобразования. После компилирования и запуска мы видим, что это работает:

$ ch06-echodate

Enter a Date/time as YYYY/MM/DD HH:MM:SS : 2003/5/25 19:07:23

Got: Sun May 25 19:07:23 2003

6.1.5. Получение сведений о часовом поясе

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

Все процедуры разделяют общий лейтмотив; данные управляются через указатели void*, а сортировку осуществляют предоставленные пользователем функции. Обратите также внимание, что эти API применяются к данным в памяти. Структуры сортировки и поиска в файлах значительно более сложны и выходят за рамки вводного руководства, подобного данному. (Однако, команда sort хорошо работает для текстовых файлов; см. справочную страницу для sort(1). Сортировка двоичных файлов требует написания специальной программы.)

Поскольку ни один алгоритм не работает одинаково хорошо для всех приложений, имеются несколько различных наборов библиотечных процедур для сопровождения искомых коллекций данных. Данная глава рассматривает лишь один простой интерфейс для поиска. Другой, более развитый интерфейс описан в разделе 14.4 «Расширенный поиск с использованием двоичных деревьев». Более того, мы намеренно не объясняем лежащие в основе алгоритмы, поскольку данная книга об API, а не об алгоритмах и структурах данных. Важно понять, что API можно рассматривать как «черные ящики», выполняющие определенную работу без необходимости понимания подробностей их работы.

6.2.1. Сортировка:

qsort()

6.2.2. Бинарный поиск:

bsearch()

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

/* ifind --- линейный поиск, возвращает найденный индекс или -1 */

int ifind(int x, const int array[], size_t nelems) {

 size_t i;

 for (i = 0; i < nelems; i++)

  if (array(i) == x) /* найдено */

   return i;

 return -1;

}

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

Недостатком линейного поиска является то, что он медленный. В среднем для массива, содержащего nelems элементов, при линейном поиске случайного элемента требуется 'nelems/2' сравнений, прежде чем найдется нужный элемент. Это становится чрезмерно дорогим даже на современных высокопроизводительных системах, когда nelems принимает большие значения. Поэтому линейный поиск следует использовать лишь с небольшими массивами.

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

Преимуществом бинарного поиска, и значительным, является то, что бинарный поиск умопомрачительно быстр, требуя самое большее log2(N) сравнений, где N является числом элементов в массиве. Функция bsearch() объявлена следующим образом:

#include /* ISO С */

void *bsearch(const void *key, const void *base, size_t nmemb,

 size_t size, int (*compare)(const void*, const void*));

Параметры и их назначение сходны с таковыми для qsort():

const void *key

Объект, который ищется в массиве.

const void *base

Начало массива.

size_t nmemb

Число элементов в массиве.

size_t size

Размер каждого элемента, полученный с помощью sizeof.

int (*compare)(const void*, const void*)

Функция сравнения. Она должна работать таким же образом, как функция сравнения для qsort(), возвращая отрицательные/нулевые/положительные значения в соответствии с тем, меньше/равен/больше первый параметр по сравнению со вторым.

Если объект не найден, bsearch() возвращает NULL. В противном случае она возвращает указатель на найденный объект. Если key соответствует более одного объекта, какой из них будет возвращен, не определено. Поэтому, как и в случае с qsort(), убедитесь, что функция сравнения принимает во внимание все существенные части искомой структуры данных.

ch06-searchemp.c показывает bsearch() на практике, расширяя использованный ранее пример struct employee:

1  /* ch06-searchemp.с ---- Демонстрация bsearch(). */

2

3  #include

4  #include

5  #include

6

7  struct employee {

8   char lastname[30];

9   char firstname[30];

10  long emp_id;

11  time_t start_date;

12 };

13

14 /* emp_id_compare --- сравнение по ID */

15

16 int emp_id_compare(const void *e1p, const void *e2p)

17 {

18  const struct employee *e1, *e2;

19

20  e1 = (const struct employee*)e1p;

21  e2 = (const struct employee*)e2p;

22

23  if (e1->emp_id < e2->emp_id)

24   return -1;

25  else if (e1->emp_id == e2->emp_id)

26   return 0;

27  else

28   return 1;

29 }

30

31 /* print_employee --- напечатать структуру сотрудника */

32

33 void print_employee(const struct employee *emp)

34 {

35  printf("%s %s\t%d\t%s", emp->lastname, emp->firstname,

36  emp->emp_id, ctime(&emp->start_date));

37 }

Строки 7–12 определяют struct employee; она та же, что и раньше. Строки 16–29 служат в качестве функции сравнения как для qsort(), так и для bsearch(). Они сравнивают лишь ID сотрудников. Строки 33–37 определяют print_employee(), которая является удобной функцией для печати структуры, поскольку это делается из разных мест.

39 /* main --- демонстрация сортировки */

40

41 int main(int argc, char **argv)

42 {

43 #define NPRES 10

44  struct employee presidents[NPRES];

45  int i, npres;

46  char buf[BUFSIZ];

47  struct employee *the_pres;

48  struct employee key;

49  int id;

50  FILE *fp;

51

52  if (argc != 2) {

53   fprintf(stderr, "usage: %s datafile\n", argv[0]);

54   exit(1);

55  }

56

57  if ((fp = fopen(argv[1], "r")) == NULL) {

58   fprintf(stderr, "%s: %s: could not open: %s\n", argv[0],

59    argv[1], strerror(errno));

60   exit(1);

61  }

62

63  /* Очень простой код для чтения данных: */

64  for (npres = 0; npres < NPRES && fgets(buf, BUFSIZ, fp) != NULL;

65   npres++) {

66   sscanf(buf, "%s %s %ld %ld",

67    presidents[npres].lastname,

68    presidents[npres].firstname,

69    &presidents[npres].emp_id,

70    &presidents[npres].start_date);

71  }

72  fclose(fp);

73

74  /* В npres теперь число действительно прочитанных строк. */

75

76  /* Сначала отсортировать по id */

77  qsort(presidents, npres, sizeof(struct employee), emp_id_compare);

78

79  /* Напечатать результат */

80  printf("Sorted by ID:\n");

81  for (i = 0; i < npres; i++) {

82   putchar('\t');

83   print_employee(&presidents[i]);

84  }

85

86  for (;;) {

87   printf("Enter ID number: ");

88   if (fgets(buf, BUFSIZ, stdin) == NULL)

89    break;

90

91   sscanf(buf, "%d\n", &id);

92   key.emp_id = id;

93   the_pres = (struct employee*)bsearch(&key, presidents,

94    npres, sizeof(struct employee), emp_id_compare);

95

96   if (the_pres != NULL) {

97    printf("Found: ");

98    print_employee(the_pres);

99   } else

100   printf("Employee with ID %d not found'\n", id);

101  }

102

103  putchar('\n'); /* Напечатать в конце символ новой строки. */

104

105  exit(0);

106 }

Функция main() начинается с проверки аргументов (строки 52–55). Затем она читает данные из указанного файла (строки 57–72). Стандартный ввод для данных сотрудников использоваться не может, поскольку он зарезервирован для запроса у пользователя ID искомого сотрудника.

Строки 77–84 сортируют, а затем печатают данные. Затем программа входит в цикл, начинающийся со строки 86. Она запрашивает идентификационный номер сотрудника, выходя из цикла по достижению конца файла. Для поиска в массиве мы используем struct employee с именем key. Достаточно лишь установить в его поле emp_id введенный номер ID; другие поля при сравнении не используются (строка 92).

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

$ ch06-searchemp presdata.txt /* Запуск программы */

Sorted by ID:

  Carter James    39 Thu Jan 20 13:00:00 1977

  Reagan Ronald   40 Tue Jan 20 13:00:00 1981

  Bush George     41 Fri Jan 20 13:00:00 1989

  Clinton William 42 Wed Jan 20 13:00:00 1993

  Bush George     43 Sat Jan 20 13:00:00 2001

Enter ID number: 42 /* Ввод действительного номера */

Found: Clinton William 42 Wed Jan 20 13:00:00 1993 /* Найдено */

Enter ID number: 29 /* Ввод неверного номера */

Employee with ID 29 not found! /* He найдено */

Enter ID number: 40 /* Попытка другого верного номера */

Found: Reagan Ronald 40 Tue Jan 20 13:00:00 1981 /* Этот тоже найден */

Enter ID number: ^D /* CTRL-D в качестве конца файла */

$ /* Готов к приему следующей команды */

Дополнительный, более продвинутый API для поиска коллекций данных описан в разделе 14.4 «Расширенный поиск с использованием двоичных деревьев».

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

Ранние системы Unix хранили информацию, сопоставляющую имена с номерами ID, в простых текстовых файлах /etc/passwd и /etc/group. На современных системах эти файлы до сих пор существуют, а их формат не изменился после V7 Unix. Однако, они больше не определяют данные полностью. Большие установленные системы с множеством сетевых хостов хранят сведения в сетевых базах данных, которые представляют собой способ хранения информации на небольшом числе серверов, доступ к которым осуществляется через сеть. Однако, такое использование прозрачно для большинства приложений, поскольку доступ к информации осуществляется через тот самый API, который использовался для получения сведений из текстовых файлов. Именно по этой причине POSIX стандартизует лишь API; в совместимой с POSIX системе файлы /etc/passwd и /etc/group не обязательно должны существовать.

API для этих двух баз данных похожи; большая часть обсуждения фокусируется на базе данных пользователей.

6.3.1. База данных пользователей

Традиционный формат /etc/passwd поддерживает по одной строке на пользователя. В каждой строке есть несколько полей, каждое из которых отделено от следующего символом двоеточия:

$ grep arnold /etc/passwd

arnold:x:2076:10:Arnold D. Robbins:/home/arnold:/bin/bash

По порядку эти поля следующие:

Имя пользователя

Это то, что пользователь набирает при регистрации, что отображается с помощью 'ls -l', а также используется в любом другом контексте при отображении пользователей.

Поле пароля

На старых системах здесь хранился зашифрованный пароль пользователя. На новых системах в этом поле скорее всего стоит x (как в данном случае), это означает, что сведения о пароле находятся в другом файле. Это разделение является средством обеспечения безопасности; если непривилегированному пользователю недоступен зашифрованный пароль, его значительно сложнее «взломать».

ID пользователя

Должен быть уникальным; один номер на пользователя.

ID группы

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

Настоящее имя пользователя

Это по крайней мере имя и фамилия пользователя. Некоторые системы допускают разделяемые запятыми поля для местоположения офиса, номера телефона и т.д., но это не стандартизовано.

Входной каталог

Этот каталог становится домашним каталогом для пользователей, когда они зарегистрируются в системе ($HOME — по умолчанию для команды cd).

Входная программа

Программа, которая запускается при регистрации пользователя. Обычно это оболочка, но не обязательно. Если это поле оставлено пустым, по умолчанию используется /bin/sh.

Доступ к базе данных пользователей осуществляется через процедуры, объявленные в :

#include /* XSI */

#include

struct passwd *getpwent(void);

void setpwent(void);

void endpwent(void);

struct passwd *getpwnam(const char *name);

struct passwd *getpwuid(uid_t uid);

Поля в struct passwd, использующиеся различными процедурами API, напрямую соответствуют полям файла паролей.

struct passwd {

 char *pw_name;   /* имя пользователя */

 char *pw_passwd; /* пароль пользователя */

 uid_t pw_uid;    /* id пользователя */

 gid_t pw_gid;    /* id группы */

 char *pw_gecos;  /* настоящее имя */

 char *pw_dir;    /* домашний каталог */

 char *pw_shell;  /* программа оболочки */

};

(Имя pw_gecos историческое; когда разрабатывались ранние системы Unix, это поле содержало соответствующие сведения для учетной записи пользователя на системах Bell Labs Honeywell с операционной системой GECOS.)

Назначение каждой процедуры описано в следующем списке.

struct passwd *getpwent(void)

Возвращает указатель на внутреннюю структуру static struct passwd, содержащую сведения о «текущем» пользователе. Эта процедура читает всю базу данных паролей, по одной записи за раз, возвращая указатель на структуру для каждого пользователя. Каждый раз возвращается тот же самый указатель; т.е. для каждой записи пользователя внутренняя struct passwd переписывается заново. Когда getpwent() достигает конца базы данных паролей, она возвращает NULL. Таким образом, она позволяет пройти через всю базу данных по одному пользователю за раз. Порядок, в котором возвращаются записи, не определен.

void setpwent(void)

Сбрасывает внутреннее состояние, так что следующий вызов getpwent() возвращает первую запись в базе данных паролей.

void endpwent(void)

«Закрывает базу данных», так сказать, будь то простой файл, сетевое соединение или что-нибудь еще.

struct passwd *getpwnam(const char *name)

Ищет пользователя с членом pw_name, соответствующим name, возвращая указатель на static struct passwd, описывающий пользователя, или NULL, если пользователь не найден.

struct passwd *getpwuid(uid_t uid)

Сходным образом ищет пользователя с номером ID, приведенным в uid, возвращая указатель на static struct passwd, описывающий пользователя, или NULL, если пользователь не найден.

getpwuid() — вот что нужно, когда есть номер ID пользователя (такой, как в struct stat) и вам нужно вывести имя соответствующего пользователя. getpwnam() преобразует имя в номер ID пользователя, например, если вы хотите использовать с файлом chown() или fchown(). Теоретически обе эти процедуры осуществляют линейный поиск по базе данных паролей для обнаружения нужных сведений. На практике это верно, когда используется файл паролей, однако, кулуарные базы данных (сетевые или другие, как на системах BSD) склоняются к использованию более эффективных методов хранения, так что эти вызовы, возможно, в таком случае не такие дорогие.

getpwent() полезна, когда нужно пройти через всю базу данных паролей. Например, может быть необходимо прочесть ее всю в память, отсортировать, а затем осуществить быстрый поиск с помощью bsearch(). Это очень полезно для избежания множества линейных поисков, свойственных поиску по одному элементу за раз с помощью getpwuid() или getpwnam().

ЗАМЕЧАНИЕ . Указатели, возвращаемые getpwent() , getpwnam() и getpwuid() , все указывают на внутренние static данные. Поэтому следует сделать копию их содержимого, если нужно сохранить сведения.

Хорошенько рассмотрите определение struct passwd . Члены, представляющие символьные строки, являются указателями, они также указывают на внутренние static данные, и если вы собираетесь скопировать структуру, не забудьте также скопировать и данные, на которые указывает каждый член структуры.

6.3.2. База данных групп

Формат базы данных групп /etc/group подобен формату /etc/passwd, но с меньшим числом полей.

$ grep arnold /etc/group

mail:x:12:mail,postfix,arnold

uucp:x:14:uucp,arnold

floppy:x:19:arnold

devel:x:42:miriam,arnold

arnold:x:2076:arnold

Опять-таки на одну группу отводится одна строка, с полями, разделенными двоеточием. Поля следующие.

Имя группы

Это имя группы, как оно отображается в 'ls -l' или в любом другом контексте, когда требуется имя группы.

Пароль группы

Историческое поле. Оно больше не используется.

ID группы

Как и для ID пользователя, должен быть уникальным для каждой группы.

Список пользователей

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

В предыдущем примере мы видели, что пользователь arnold является членом нескольких групп. Это членство на практике отражается в том, что называют набором групп (group set). Помимо главных номеров ID пользователя и ID группы, которые есть у процессов, набор групп является набором номеров ID дополнительных групп, который имеет при себе каждый процесс. Система проверяет на соответствие с этими ID групп, ID группы файла при осуществлении проверки прав доступа. Эта тема более подробно обсуждается в разделе 11 «Разрешения и ID пользователя и группы».

API базы данных групп сходна с API для базы данных пользователей. Следующие функции определены в :

#include /* XSI */

#include

struct group *getgrent(void);

void setgrent(void);

void endgrent(void);

struct group *getgrnam(const char *name);

struct group *getgrgid(gid_t gid);

struct group соответствует записям в /etc/group:

struct group {

 char *gr_name;   /* имя группы */

 char *gr_passwd; /* пароль группы */

 gid_t gr_gid;    /* id группы */

 char **gr_mem;   /* члены группы */

};

Поле gr_mem требует некоторого объяснения. Хотя оно объявлено в виде указателя на указатель (char**), лучше представить его как массив строк (наподобие argv). Последний элемент в массиве устанавливается в NULL. Когда в списке нет членов, первый элемент массива равен NULL.

ch06-groupinfo.с демонстрирует, как использовать struct group и поле gr_mem. Программа принимает в командной строке имя единственного пользователя и печатает все записи групп, в которых появляется этот пользователь:

1  /* ch06-groupinfo.с --- Демонстрация getgrent() и struct group */

2

3  #include

4  #include

5  #include

6

7  extern void print_group(const struct group *gr);

8

9  /* main --- вывести строки групп для пользователя в argv[1] */

10

11 int

12 main(int argc, char **argv)

13 {

14  struct group *gr;

15  int i;

16

17  if (argc != 2) { /* Проверка аргументов */

18   fprintf(stderr, "usage: %s user\n", argv[0]);

19   exit(1);

20  }

21

22  while ((gr = getgrent()) != NULL) /* Получить запись каждой группы: */

23   for (i = 0; gr->gr_mem[i] != NULL; i++) /* Рассмотреть каждый член */

24    if (strcmp(gr->gr_mem[i], argv[i]) == 0) /* Если пользователь найден... */

25     print_group(gr); /* Вывести запись */

26

27  endgrent();

28

29  exit(0);

30 }

Функция main() сначала проверяет ошибки (строки 17–20). Основным компонентом программы является вложенный цикл. Внешний цикл (строка 22) перечисляет все записи базы данных группы. Внутренний цикл (строка 23) перечисляет всех членов массива gr_mem. Если один из членов соответствует имени из командной строки (строка 24), для печати записи вызывается print_group() (строка 25):

32 /* print_group --- печать записи группы */

33

34 void

35 print_group(const struct group *gr)

36 {

37  int i;

38

39  printf("%s:%s:%ld:gr->gr_name, gr->gr_passwd, (long)gr->gr_gid);

40

41  for (i = 0; gr->gr_mem[i] != NULL; i++) {

42   printf("%s", gr->gr_mem[i]);

43   if (gr->gr_mem[i+1) != NULL)

44    putchar(',');

45  }

46

47  putchar('\n');

48 }

Функция print_group() (строки 34–48) проста, ее логика подобна логике main() для печати списка членов. Члены списка группы разделены запятыми; поэтому тело цикла до вывода запятой должно проверить, что следующий элемент в массиве не является NULL. Этот код работает правильно, даже если в группе нет членов. Однако мы знаем, что для этой программы есть члены, иначе print_group() не была бы вызвана! Вот что происходит при запуске программы:

$ ch06-groupinfo arnold

mail:x:12:mail,postfix,arnold

uucp:x:14:uucp,arnold

floppy:x:19:arnold

devel:x:42:miriam,arnold

arnold:x:2076:arnold

Унифицированное иерархическое пространство имен файлов является большим достоинством дизайна Linux/Unix. Данный раздел рассматривает, как административные файлы, команды и операционная система объединяются для построения пространства имен из отдельных физических устройств, содержащих данные и служебные данные файлов.

8.1.1. Обзор основ

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

Помимо индексов и блоков данных, файловые системы содержат также одну или более копий суперблока. Это специальный дисковый блок, который описывает файловую систему; его сведения обновляются по мере изменений в самой файловой системе. Например, он содержит число свободных и используемых индексов, свободных и используемых блоков и другие сведения. Он включает также магическое число: специальное уникальное значение в специальном месте, которое идентифицирует тип файловой системы (Вскоре мы увидим, насколько это важно.)

Обеспечение доступа к разделу, содержащему файловую систему, называется монтированием (mounting) файловой системы. Удаление файловой системы из использования называется, что неудивительно, демонтированием (unmounting) файловой системы.

Эти две задачи выполняются программами mount и umount [так], названными по соответствующим системным вызовам. У системного вызова mount() каждой системы Unix свой, отличный интерфейс. Поскольку монтирование и демонтирование считаются проблемой реализации, POSIX намеренно не стандартизует эти системные вызовы

Вы монтируете файловую систему в каталог; такой каталог называется точкой монтирования файловой системы. По соглашению, каталог должен быть пустым, но ничто не принуждает к этому. Однако, если точка монтирования не пуста, все ее содержимое становится , пока в ней не смонтирована файловая система.

Ядро поддерживает уникальный номер, известный как номер устройства, который идентифицирует каждый смонтированный раздел. По этой причине именно пара (устройство, индекс) вместе уникально идентифицируют файл; когда структуры struct stat для двух имен файлов указывают, что оба эти номера одни и те же, можно быть уверенным, что они на самом деле ссылаются на один и тот же файл.

Как упоминалось ранее, программы уровня пользователя помещают структуры индексов и другие вспомогательные данные на раздел диска, создавая тем самым файловую систему. Эти самые программы создают для файловой системы начальный корневой каталог. Таким образом, нам придется провести различие между «корневым каталогом, названным /», который является каталогом самого верхнего уровня в иерархическом пространстве имен файлов, и «корневым каталогом файловой системы», который является отдельным каталогом верхнего уровня каждой файловой системы. Каталог / является также «корневым каталогом» «корневой файловой системы».

По причинам, описанным на врезке, у корневого каталога файловой системы номер индекса всегда равен 2 (хотя это не стандартизовано формально). Поскольку может быть несколько файловых систем, у каждой из них один и тот же номер индекса корневого каталога 2. При разрешении пути ядро знает, где смонтирована каждая файловая система и заставляет имя точки монтирования ссылаться на корневой каталог смонтированной файловой системы. Более того, '..' в корне смонтированной файловой системы ссылается на родительский каталог точки монтирования.

На рис. 8.1 показаны две файловые системы: одна для корневого каталога, а другая для /usr, до того, как /usr смонтирована. На рис. 8.2 показана ситуация после монтирования /usr.

Рис. 8.1. Отдельные файловые системы до монтирования

Рис. 8.2. Отдельные файловые системы после монтирования

Каталог /, корень всей логической иерархии, особый еще в одном отношении: /. и /.. ссылаются на один и тот же каталог; это неверно для любого другого каталога в системе. (Таким образом, после команды типа 'cd /../../../..' вы все еще будете в /.) Это поведение реализуется простым способом: как /., так и /.. являются прямыми ссылками на корневой каталог файловой системы. (Вы можете видеть это как на рис. 8.1, так и 8.2.) Каждая файловая система работает таким способом, но ядро рассматривает / особым образом и не рассматривает как особый случай каталог '..' для файловой системы, смонтированной в /.

Номера индексов корневого каталога

Номер индекса для корневого каталога файловой системы всегда равен 2. Почему это так? Ответ имеет отношение как к технологии, так и к истории.

Как упоминалось в разделе 5.3 «Чтение каталогов», элемент каталога с номером индекса ноль означает неиспользуемый, или пустой слот. Поэтому индекс 0 не может использоваться для настоящего файла или каталога.

Хорошо, так что насчет индекса 1? Ну, особенно в 70-80 годах XX века, диски не были сделаны так же хорошо, как сейчас. Когда вы покупали диск, он приходил с (бумажным) списком испорченных блоков — известных мест на диске, которые не могли быть использованы. Каждой операционной системе приходилось отслеживать эти плохие блоки и избегать их использования.

Под Unix это осуществлялось созданием файла особого назначения, блоки данных которого были известны, как испорченные. Этот файл присоединялся к индексу 1, оставляя 2 в качестве первого индекса, доступного для использования обычными файлами или каталогами.

На современных дисках присутствует значительное количество встроенной электроники, и они сами управляют испорченными блоками. Поэтому технически было бы осуществимо использовать для файла индекс 1. Однако, поскольку такое большое количество программ Unix, которые предполагают, что индекс 2 является индексом для корневых каталогов файловых систем, Linux также следует этому соглашению. (Однако, Linux иногда использует индекс 1 для не собственных файловых систем, таких, как vfat или /proc .)

8.1.2. Обзор различных типов файловых систем

ЗАМЕЧАНИЕ . Обсуждение в данном разделе специфично для Linux. Однако, у многих современных систем Unix также есть сходные особенности. Мы рекомендуем вам изучить документацию своей системы.

Исторически V7 Unix поддерживал лишь один тип файловой системы; вспомогательные данные и организация каталогов каждого из разделов были структурированы одним и тем же способом. 4.1 BSD использовал файловую систему с такой же как у V7 структурой, но с размером блока 1024 байта вместо 512 байтов. 4.2 BSD ввело «файловую систему BSD», которая разительно изменила расположение индексов и данных на диске и дала возможность использовать гораздо большие размеры блоков. (В общем, использование больших протяженных блоков данных обеспечивает лучшую производительность, особенно для чтения файлов.)

Вплоть до 4.3 BSD и System V Release 2 в начале и середине 1980-х системы Unix продолжали поддерживать один тип файловой системы. Для переключения компьютера от одной файловой системы на другую приходилось сначала резервировать каждую файловую систему на среду архивирования (9-дорожечную ленту), обновлять систему, а затем восстанавливать данные.

В середине 1980-х Sun Microsystems разработала архитектуру ядра, которая сделала возможным использование нескольких архитектур файловой системы в одно и то же время. Этот проект был реализован в их операционной системе SunOS, сначала для поддержки сетевой файловой системы Sun (Network File System — NFS). Однако, как следствие, стало возможным также поддерживать несколько архитектур на диске. System V Release 3 использовала сходную архитектуру для поддержки удаленной файловой системы (Remote File System — RFS), но она продолжала поддерживать лишь одну архитектуру на диске. (RFS никогда широко не использовалась и сейчас является лишь исторической сноской.)

Общий дизайн Sun стал популярным и широко реализовывался в коммерческих системах Unix, включая System V Release 4. Системы Linux и BSD используют разновидность этого дизайна для поддержки множества форматов файловых систем на диске. В частности, обычным для всех разновидностей Unix на платформе Intel x86 является возможность монтирования файловых систем MS-DOS/Windows FAT, включая поддержку длинных имен, а также форматированные в соответствии с ISO 9660 CD-ROM.

Linux имеет несколько собственных (т.е. размещаемых на диске) файловых систем. Наиболее популярными являются файловые системы ext2 и ext3. Однако, доступно значительно больше файловых систем. Сведения о большинстве из них вы можете найти в каталоге /usr/src/linux/Documentation/filesystems/ (если вы установили исходный код ядра). В табл. 8.1 перечислены имена различных файловых систем с кратким описанием каждой из них. Сокращение «RW» означает «чтение/запись», a «RO» означает «только чтение».

Таблица 8.1. Поддерживаемые ядром файловые системы Linux (ядро 2.4.x)

Не все из этих файловых систем поддерживаются командой mount; список поддерживаемых см. в mount(8).

Журналирование является методикой, впервые использованной в системах баз данных для увеличения производительности обновлений файлов таким образом, что восстановление файловой системы в случае аварии могло быть сделано быстро и правильно. В момент написания этого были доступны несколько различных журналируемых файловых систем, конкурирующих за продвижение в мире GNU/Linux. Одной из них является ext3; у нее преимущество обратной совместимости с существующими файловыми системами ext2, очень просто конвертировать файловые системы туда-сюда между этими двумя видами (См. tune2fs(8).) ReiserFS и XFS также имеют своих твердых сторонников.

Файловые системы fat, msdos, umsdos и vfat все разделяют общий исходный код. В общем, можно использовать vfat для монтирования разделов Windows FAT-32 (или другой FAT-xx), a umsdos, если нужно использовать раздел FAT в качестве корневой файловой системы для GNU/Linux.

Файловые системы Coherent, MINIX, первоначальной System V и Xenix все имеют сходные структуры на диске. Тип файловой системы sysv поддерживает все из них; четыре имени coherent, minix, sysv и xenix являются псевдонимами один для другого. Имена coherent и xenix в конечном счете будут удалены.

Быстрая файловая система BSD в течение нескольких лет успешно развилась. Файловая система ufs поддерживает операции чтения/записи для версий, начиная с 4.4 BSD, которая является основой для трех широко распространенных операционных систем BSD: FreeBSD, NetBSD и OpenBSD. Она поддерживает также операции чтения/записи для файловой системы Sun Solaris как для SPARC, так и для систем Intel x86. Первоначальный формат BSD и формат операционной системы NeXTStep поддерживаются в режиме только для чтения.

Обозначения «RO» для befs и ntfs означают, что файловые системы этих типов можно смонтировать и читать, но в них невозможно записать файлы или удалить из них файлы. (Со временем это может измениться; проверьте документацию своей системы.) Файловые системы cramfs, iso9660, romfs и udf отмечены «RO», поскольку лежащее в их основе средство по своей сути является устройством только для чтения.

Две файловые системы, которых больше не существует, это ext, которая была оригинальной расширенной файловой системой, и xiafs, которая расширяла оригинальную файловую систему MINIX для использования длинных имен и больших размеров файлов, xiafs и ext2 появились примерно в одно время, но ext2 в конечном счете стала доминирующей файловой системой.

8.1.3. Монтирование файловых систем:

mount

Команда mount монтирует файловые системы, соединяя их содержимое в системную иерархию файлов в их точках монтирования. Под GNU/Linux это иногда запутано, поскольку приходится иметь дело со всеми известными типами файловых систем и их опциями. Обычно запустить mount может лишь root, хотя в некоторых случаях можно сделать исключения, как в случае, обсуждаемом далее в главе.

Файловую систему вы указываете с помощью опции -t:

mount [ опции ] устройство точка _монтирования

Например (# является приглашением для root):

# mount -t iso9660 /dev/cdrom /mnt/cdrom /* Монтировать CD-ROM */

# mount -t vfat /dev/fd0 /mnt/floppy /* Монтировать гибкий диск MS-DOS */

# mount -t nfs files.example.com:/ /mnt/files /* Монтировать файловую систему NFS */

Можно использовать '-t auto', чтобы заставить mount угадать тип файловой системы. Это обычно работает, хотя если вы точно знаете, каков тип файловой системы, опция '-t' помогает указать тип и избежать вероятности ошибочного определения файловой системы, mount по умолчанию угадывает нужный тип, поэтому '-t auto' не является абсолютно необходимым.

Системы GNU/Linux предусматривают специальную разновидность монтирования посредством кольцевого (loopback) устройства. Таким способом образ файловой системы, содержащийся в обычном файле, может быть смонтирован, как если бы это было настоящее дисковое устройство. Эта возможность очень полезна, например, при использовании образов CD-ROM. Она позволяет создать образ и испытать его без необходимости прожига на болванке CD с последующим его монтированием. Следующий пример использует первый образ CD из дистрибутива GNU/Linux RedHat 9:

# ls -l shrike-i386-discl.iso /* Исследование файла образа CD */

-rw-r--r-- 1 arnold devel 668991488 Apr 11 05:13 shrike-i386-discl.iso

# mount -t iso9660 -o ro,loop shrike-i386-discl.iso /mnt/cdrom

/* Смонтировать его в /mnt/cdrom */

# cd /mnt/cdrom /* Перейти туда */

# ls /* Посмотреть файлы */

autorun              README.it             RELEASE-NOTES-fr.html

dosutils             README.ja             RELEASE-NOTES.html

EULA                 README.ko             RELEASE-NOTES-it.html

GPL                  README.pt             RELEASE-NOTES-ja.html

images               README.pt_BR          RELEASE-NOTES-ko.html

isolinux             README.zh_CN          RELEASE-NOTES-pt_BR.html

README               README.zh_TW          RELEASE-NOTES-pt.html

README-Accessibility RedHat                RELEASE-NOTES-zh_CN.html

README.de            RELEASE-NOTES         RELEASE-NOTES-zh_TW.html

README.es            RELEASE-NOTES-de.html RPM-GPG-KEY

README.fr            RELEASE-NOTES-es.html TRANS.TBL

# cd /* Сменить */

# umount /mnt/cdrom /* Демонтировать */

Возможность монтирования таким способом образа ISO 9660 особенно полезна при тестировании сценариев, создающих образы CD. Вы можете создать образ в обычном файле, смонтировать его и проверить, что он подготовлен правильно. Затем, убедившись, что все в порядке, можно скопировать образ на записываемый CD («прожечь» CD). Возможность кольцевого устройства полезна также для монтирования образов гибких дисков

8.1.4. Демонтирование файловых систем:

umount

Команда umount демонтирует файловую систему, удаляя ее содержимое из системной иерархии файлов. Использование следующее:

umount файл-или-устройство

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

$ mount /* Показать, что смонтировано */

/dev/hda2 on / type ext3 (rw) /* / находится на настоящем устройстве */

none on /proc type proc (rw)

usbdevfs on /proc/bus/usb type usbdevfs (rw)

/dev/hda5 on /d type ext3 (rw) /* To же c /d */

none on /dev/pts type devpts (rw,gid=5,mode=620)

none on /dev/shm type tmpfs (rw)

none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

$ su /* Переключиться на суперпользователя */

Password: /* Пароль не отображается */

# cd /d /* Сделать /d текущим каталогом */

# umount /d /* Попытка демонтировать /d */

umount: /d: device is busy /* Doesn't work; it's still in use */

# cd / /* Сменить /d */

# umount /d /* Еще одна попытка демонтировать /d */

# /* Молчание золото: umount работает */

Файл /etc/fstab перечисляет файловые системы, которые могут быть смонтированы. Большинство из них монтируются автоматически, когда система загружается. Формат следующий:

устройство точка-монтирования тип-фс опции dump-freq fsck-pass

(dump-freq и fsck-pass являются административными особенностями, не относящимися к настоящему обсуждению). Например, на нашей системе файл выглядит следующим образом:

$ cat /etc/fstab

# device mount-point type options freq passno

/dev/hda3 / ext3 defaults 1 1 /* Корневая файловая система */

/dev/hda5 /d ext3 defaults 1 2

none /dev/pts devpts gid=5,mode=620 0 0

none /proc proc defaults 0 0

none /dev/shm tmpfs defaults 0 0

# Windows partition:

/dev/hda1 /win vfat noauto,defaults,user,uid=2076,gid=10 0 0

/dev/hda3 swap swap defaults 0 0

/dev/cdrom /mnt/cdrom iso9660 noauto,owner,ro 0 0 /* Монтируемый */

/dev/fd0 /mnt/floppy auto noauto,owner 0 0/* Гибкий диск, то же самое */

Разрешены комментарии, начинающиеся с #. Вскоре, в разделе 8.2 1 «Использование опций монтирования», будет обсуждение различных опций.

Тот же самый формат файла используется для /etc/mtab, куда mount записывает информацию о файловых системах, когда они смонтированы; umount удаляет информацию из этого файла, когда файловая система демонтирована:

$ cat /etc/mtab

/dev/hda2 / ext3 rw 0 0

none /proc proc rw 0 0

usbdevfs /proc/bus/usb usbdevfs rw 0 0

/dev/hda5 /d ext3 rw 0 0

none /dev/pts devpts rw,gid=5,mode=620 0 0

none /dev/shm tmpfs rw 0 0

none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0

/dev/hda1 /win vfat rw,noexec,nosuid,nodev,uid=2076,gid=10,user=arnold 0 0

Ядро делает доступным (почти) те же самые сведения в /proc/mounts, в том же формате:

$ cat /proc/mounts

rootfs / rootfs rw 0 0

/dev/root / ext3 rw 0 0

/proc /proc proc rw 0 0

usbdevfs /proc/bus/usb usbdevfs rw 0 0

/dev/hda5 /d ext3 rw 0 0

none /dev/pts devpts rw 0 0

none /dev/shm tmpfs rw 0 0

none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0

/dev/hda1 /win vfat rw,nosuid,nodev,noexec 0 0

Обратите внимание, что в /etc/mtab есть некоторые сведения, которые отсутствуют в /proc/mounts. (Например, см. строку для точки монтирования /win.) С другой стороны, возможно (используя 'mount -f') помещать в /etc/mtab элементы, которые не являются настоящими (эта практика имеет свое применение, см. mount(8)). Подводя итог, /proc/mounts всегда описывает, что смонтировано в действительности; однако, /etc/mtab содержит сведения об опциях mount, которых нет в /proc/mounts. Поэтому, чтобы получить полную картину, вам может понадобиться прочесть оба файла

8.2.1. Использование опций монтирования

Команда mount поддерживает опции, которые контролируют то, какие операции ядро будет позволять или не позволять применять к файловой системе. Их приличное количество. Лишь две из них полезны на самом деле в командной строке:

ro

Монтирует файловую систему только для чтения. Это необходимо для устройств только для чтения, таких, как CD-ROM и DVD.

loop

Использует кольцевое устройство для интерпретации обычного файла в качестве файловой системы. Пример этого мы показали ранее (см. раздел 8.1.3 «Монтирование файловых систем: mount»).

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

mount -t iso9660 -о ro,loop shrike-i386-discl.iso /mnt/cdrom

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

auto, noauto

Файловые системы, помеченные auto, должны монтироваться при загрузке системы через 'mount -а' (монтировать все файловые системы). Файловые системы noauto должны монтироваться вручную. Они по-прежнему находятся в /etc/fstab вместе с другими файловыми системами. (См., например, элемент /win для показанного ранее файла /etc/fstab).

defaults

Использует по умолчанию опции rw, suid, dev, exec, auto, nouser и async. (async является продвинутой опцией, повышающей производительность ввода/вывода).

dev, nodev

Позволяет (не позволяет) использовать в файловой системе файлы символьных или блочных устройств.

exec, noexec

Позволяет (не позволяет) запускать в файловой системе двоичные исполняемые файлы.

user, nouser

Позволяет (не позволяет) монтировать данную файловую систему любому пользователю. Это полезно для CD-ROM; даже если вы находитесь на рабочей станции с одним пользователем, удобно не переключаться на root просто для монтирования CD. Демонтировать файловую систему может лишь пользователь, который смонтировал ее. user предполагает наличие опций noexec, nosuid и nodev.

suid, nosuid

Поддерживает (не поддерживает) биты setuid и setgid исполняемых файлов в файловой системе.

rw

Монтирует файловую систему в режиме для чтения/записи.

Опции nodev, noexec и nosuid особенно ценны для безопасности на файловых системах гибких дисков и CD-ROM. Рассмотрите студенческую среду, в которой студентам разрешено монтировать собственные гибкие диски или CD. Тривиально смастерить для жесткого диска файловую систему с оболочкой setuid-root или с файлом устройства с разрешением записи для всех, которая позволила бы предприимчивому пользователю изменить права доступа к системным файлам.

У каждой файловой системы есть специфичные для нее опции. Важной опцией для ext2 и ext3 является grpid. Мы отложим обсуждение этой опции до раздела 11.5.1 «Группа по умолчанию для новых файлов и каталогов». Подробности для всех поддерживаемых файловых систем можно найти в справочной странице mount(8).

В качестве конкретного примера вернемся к строчке для раздела Windows в нашей системе:

# device mount-point type options freq passno

/dev/hda1 /win vfat noauto,defaults,user,uid=2076,gid=10 0 0

Опция noauto предотвращает монтирование раздела Windows при загрузке. Опция defaults та же самая, что rw, suid, dev, exec, async. Опция user позволяет нам монтировать файловую систему, не будучи root. Опции uid= и gid= делает файлы в /win принадлежащими нам, так что нам не нужно иметь права root при работе с этим разделом.

8.2.2. Работа со смонтированными файловыми системами:

getmntent()

Любой из файлов /etc/fstab, /etc/mtab и /proc/mounts может быть прочитан программное использованием набора процедур getmntent():

#include /* GLIBC */

#include

FILE *setmntent(const char *filename, const char *type);

struct mntent *getmntent(FILE *filep);

int addmntent(FILE *filep, const struct mntent *mnt);

int endmntent(FILE *filep);

char *hasmntopt(const struct mntent *mnt, const char *opt);

setmntent() открывает файл, содержащий элементы точек монтирования. Аргумент filename является файлом, который должен быть открыт. Аргумент type похож на второй аргумент fopen(), указывая доступ для чтения, записи или чтения/записи. (Рассмотрите команду mount, которой приходится добавлять элемент к /etc/mtab для каждой файловой системы, которую она монтирует, и umount, которая должна удалять этот элемент.) Затем возвращаемое значение типа FILE* используется с оставшимися процедурами.

getmntent() читает файл, возвращая указатель на static struct mntent, которая заполнена соответствующими значениями. Это статическое хранилище переписывается при каждом вызове. Когда больше не осталось элементов, она возвращает NULL. (Это сходно с процедурами для чтения файлов паролей и групп; см раздел 6.3 «Имена пользователей и групп».)

addmntent() вызывается для добавления сведений в конец открытого файла, она предназначена для использования функцией mount.

endmntent() закрывает открытый файл; вызывайте ее после завершения обработки. Не вызывайте просто fclose(); может потребоваться очистить другие внутренние структуры данных, связанные с переменной FILE*.

hasmntopt() является более специализированной функцией. Она просматривает struct mntent, переданную в качестве первого параметра, в поисках опции mount, совпадающей со вторым аргументом. Если опция найдена, она возвращает адрес совпадающей подстроки. В противном случае возвращается NULL.

Поля в struct mntent непосредственно соответствуют полям в файле /etc/fstab. Структура выглядит следующим образом:

struct mntent {

 char *mnt_fsname; /* Устройство или сервер для файл. С-мы. */

 char *mnt_dir;    /* Каталог для монтирования. */

 char *mnt_type;   /* Тип файловой системы: ufs, nfs и т.д. */

 char *mnt_opts;   /* Отделяемые запятыми опции для fs. */

 int mnt_freq;     /* Частота дампа (в днях). */

 int mnt_passno;    /* Номер для 'fsck'. */

};

Обычным принципом работы со смонтированными файловыми системами является создание внешнего цикла, читающего /etc/mtab, обрабатывая по одной struct mntent за раз. Наш первый пример, ch08-mounted.c, делает именно это:

1  /* ch08-mounted.с --- вывод списка смонтированных файловых

2     систем */

3  /* ЗАМЕЧАНИЕ: специфично для GNU/Linux! */

4

5  #include

6  #include

7  #include /* для getmntent() и др. */

8  #include /* для getopt() */

9

10 void process(const char *filename);

11 void print_mount(const struct mntent *fs);

12

13 char *myname;

14

15 /* main --- обработка опций */

16

17 int main(int argc, char **argv)

18 {

19  int c;

20  char *file = "/etc/mtab"; /* файл по умолчанию для чтения */

21

22  myname = argv[0];

23  while ((c = getopt(argc, argv, "f:")) != -1) {

24   switch (c) {

25   case 'f':

26    file = optarg;

27    break;

28   default:

29    fprintf(stderr, "usage: %s [-f fstab-file]\n", argv[0]);

30    exit(1);

31   }

32  }

33

34  process(file);

35  return 0;

36 }

37

38 /* process --- прочесть структуры struct mntent из файла */

39

40 void process(const char *filename)

41 {

42  FILE *fp;

43  struct mntent *fs;

44

45  fp = setmntent(filename, "r"); /* только для чтения */

46  if (fp == NULL) {

47   fprintf(stderr, "%s: %s: could not open: %s\n",

48    myname, filename, strerror(errno));

49   exit(1);

50  }

51

52  while ((fs = getmntent(fp)) != NULL)

53   print_mount(fs);

54

55  endmntent(fp);

56 }

57

58 /* print_mount --- вывод одного смонтированного элемента */

59

60 void print_mount(const struct mntent *fs)

61 {

62  printf("%s %s %s %s %d %d\n",

63   fs->mnt_fsname,

64   fs->mnt_dir,

65   fs->mnt_type,

66   fs->mnt_opts,

67   fs->mnt_freq,

68   fs->mnt_passno);

69 }

В отличие от большинства программ, которые мы до сих пор видели, эта специфична для Linux. Во многих Unix-системах есть схожие процедуры, но их идентичность не гарантируется.

По умолчанию, ch08-mounted читает /etc/mtab, выводя сведения о каждой смонтированной файловой системе. Опция -f позволяет указать другой файл для чтения, такой, как /proc/mounts или даже /etc/fstab.

Функция main() обрабатывает командную строку (строки 23–32) и вызывает для указанного файла process(). (Эта программа следует нашему стандартному шаблону.)

process(), в свою очередь, открывает файл (строка 45) и проходит в цикле через каждую возвращённую файловую систему (строки 52–53). После завершения она закрывает файл (строка 55).

Функция print_mount() выводит информацию из struct mnent. Вывод во многом напоминает вывод 'cat /etc/mtab':

$ ch08-mounted /* Запуск программы */

/dev/hda2 / ext3 rw 0 0

none /proc proc rw 0 0

usbdevfs /proc/bus/usb usbdevfs rw 0 0

/dev/hda5 /d ext3 rw 0 0

none /dev/pts devpts rw,gid=5,mode=620 0 0

none /dev/shm tmpfs rw 0 0

none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0

/dev/hda1 /win vfat rw,noexec,nosuid,nodev,uid=2076,gid=10,user=arnold 0 0

Вывод сведений о файловой системе, рассмотренный ранее — это хорошо и замечательно, но это не захватывает. Раз мы знаем, что определенная точка монтирования представляет файловую систему, нам нужны сведения о файловой системе. Это даст нам возможность выводить вещи наподобие сведений, полученных с помощью df и 'df -i'.

$ df /* Показать свободное/используемое пространство */

Filesystem 1K-blocks Used Available Use% Mounted on

/dev/hda2 6198436 4940316 943248 84% /

/dev/hda5 61431520 27618536 30692360 48% /d

none 256616 0 256616 0% /dev/shm

/dev/hda1 8369532 2784700 5584832 34% /win

$ df -i /* Показать свободные/используемые индексы */

Filesystem Inodes IUsed IFree IUse% Mounted on

/dev/hda2 788704 233216 555488 30% /

/dev/hda5 7815168 503243 7311925 7% /d

none 64154 1 64153 1% /dev/shm

/dev/hda1 0 0 0 - /win

8.3.1. Стиль POSIX:

statvfs()

и

fstatvfs()

На ранних системах Unix была только одна разновидность файловой системы. Для них было достаточно, если df считывала суперблок каждой смонтированной файловой системы, извлекала значимые сведения и красиво форматировала их для отображения. (Суперблок обычно был вторым блоком в файловой системе; первым был загрузочный блок, содержащий загрузочный код).

Однако в современном мире такой подход был бы непригодным. POSIX предоставляет расширение XSI для получения доступа к этой информации. Главная функция называется statvfs() («vfs» часть происходит от лежащей в основе технологии SunOS, использованной позже в System V Release 4, которая называется виртуальной файловой системой.) Имеется две функции:

#include /* XSI */

#include

int statvfs(const char *path, struct statvfs *buf);

int fstatvfs(int fd, struct statvfs *buf);

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

struct statvfs {

 unsigned long int f_bsize;   /* Размер блока */

 unsigned long int f_frsize;

  /* Размер фрагмента («основной размер блока») */

 fsblkcnt_t f_blocks;         /* Общее число блоков */

 fsblkcnt_t f_bfree;          /* Общее число свободных блоков */

 fsblkcnt_t f_bavail;         /* Число доступных блоков (≤f_bfree) */

 fsfilcnt_t f_files;          /* Общее число индексов */

 fsfilcnt_t f_ffree;          /* Общее число свободных индексов */

 fsfilcnt_t f_favail;         /* Число доступных индексов (≤f_files) */

 unsigned long int f_fsid;    /* ID файловой системы */

 unsigned long int f_flag;    /* Флаги: ST_RDONLY и/или ST_NOSUID */

 unsigned long int f_namemax; /* Максимальная длина имени файла */

};

Сведений, которые в ней содержатся, достаточно для написания df:

unsigned long int f_bsize

Размер блока является предпочтительным размером для осуществления ввода/вывода. Файловая система пытается хранить по крайней мере f_bsize байтов стоящих данных в смежных секторах на диске. (Сектор является наименьшим количеством адресуемых данных на диске. Обычно дисковый сектор равен 512 байтам.)

unsigned long int f_frsize

Некоторые файловые системы (такие, как BSD Fast Filesystem) проводят различие между блоками и фрагментами блоков. Небольшие файлы, общий размер которых меньше размера блока, находятся в некотором числе фрагментов. Это позволяет избежать пустой потери дискового пространства (за счет допустимой цепы большей сложности кода ядра). Размер фрагмента выбирается во время создания файловой системы.

fsblkcnt_t f_blocks

Общее число блоков (в единицах f_bsize) в файловой системе.

fsblkcnt_t f_bfree

Общее число свободных блоков в файловой системе.

fsblkcnt_t f_bavail

Число блоков, которые действительно могут использоваться. Некоторые файловые системы резервируют часть блоков файловой системы для использования суперпользователем при заполнении файловой системы. Современные системы резервируют около 5 процентов, хотя это число может быть изменено администратором. (См. tune2fs(8) на системе GNU/Linux и tunefs(8) на системах Unix.)

fsfilcnt_t f_files

Общее число индексов («порядковых номеров файлов» на языке POSIX) в файловой системе. Это число обычно инициализируется и делается постоянным при создании файловой системы.

fsfilcnt_t f_ffree

Общее число свободных узлов.

fsfilcnt_t f_favail

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

unsigned long int f_fsid

ID файловой системы. POSIX не определяет, что оно представляет, и это под Linux не используется.

unsigned long int f_flag

Флаги, дающие информацию о файловой системе. POSIX определяет два флага: ST_RDONLY для файловых систем только для чтения (таких, как CD-ROM) и ST_NOSUID, который запрещает использование битов setuid и setgid в исполняемых файлах. Системы GNU/Linux предусматривают дополнительные флаги: они перечислены в табл. 8.2.

Таблица 8.2. Значения GLIBC для f_flag

unsigned long int f_namemax

Максимальная длина имени файла. Это относится к каждому отдельному компоненту в имени пути; другими словами, максимальная длина для элемента каталога

Типы fsblkcnt_t и fsfilcnt_t определены в . Они обычно являются unsigned long, но на современных системах они могут быть даже 64-разрядными, поскольку диски стали очень большими. Следующая программа, ch08-statvfs.c, показывает, как использовать statvfs():

1  /* ch08-statvfs.с --- демонстрация statvfs */

2

3  /* ЗАМЕЧАНИЕ: специфично для GNU/Linux! */

4

5  #include

6  #include

7  #include /* для getmntent(), et al. */

8  #include /* для getopt() */

9  #include

10 #include

11

12 void process(const char *filename);

13 void do_statvfs(const struct mntent *fs);

14

15 int errors = 0;

16 char *myname;

17

18 /* main --- обработка опций */

19

20 int main(int argc, char **argv)

21 {

22  int c;

23  char *file = "/etc/mtab"; /* файл для чтения по умолчанию */

24

25  myname = argv[0];

26  while ((c = getopt(argc, argv, "f:")) != -1) {

27   switch (c) {

28   case 'f':

29    file = optarg;

30    break;

31   default:

32    fprintf(stderr, "usage: %s [-f fstab-file]\n", argv[0]);

33    exit(1);

34   }

35  }

36

37  process(file);

38  return (errors != 0);

39 }

40

41 /* process --- чтение структур struct mntent из файла */

42

43 void process(const char *filename)

44 {

45  FILE* fp;

46  struct mntent *fs;

47

48  fp = setmntent(filename, "r"); /* только для чтения */

49  if (fp == NULL) {

50   fprintf(stderr, "%s: %s: could not open: %s\n",

51    myname, filename, strerror(errno));

52   exit(1);

53  }

54