КулЛиб - Скачать fb2 - Читать онлайн - Отзывы
Всего книг - 402681 томов
Объем библиотеки - 529 Гб.
Всего авторов - 171361
Пользователей - 91546

Впечатления

Stribog73 про Бердник: Последняя битва (Научная Фантастика)

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

Рейтинг: 0 ( 0 за, 0 против).
Stribog73 про Римский-Корсаков: Полет шмеля (Переложение В. Пахомова) (Партитуры)

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

Рейтинг: 0 ( 0 за, 0 против).
Stribog73 про Бердник: Остання битва (Научная Фантастика)

Текст вычитан.

Рейтинг: 0 ( 0 за, 0 против).
Stribog73 про Варфоломеев: Две гитары (Партитуры)

Четвертая и последняя из имеющихся у меня обработок этого романса.

Рейтинг: 0 ( 0 за, 0 против).
Stribog73 про Бердник: Остання битва (Научная Фантастика)

Спасибо огромное моему другу Мише из Днепропетровска за то, что нашел по моей просьбе и перефотографировал этот рассказ Бердника.

Рейтинг: 0 ( 0 за, 0 против).
Stribog73 про Елютин: Барыня (Партитуры)

У меня имеется довольно неплохая коллекция нот Елютина, но их надо набирать в MuseScore, как я сделал с этой обработкой. Не знаю когда будет на это время.

Рейтинг: +1 ( 1 за, 0 против).
nnd31 про Горн: Дух трудолюбия (Альтернативная история)

Пока читал бездумно - все было в порядке. Но дернул же меня черт где-то на середине книги начать думать... Попытался представить себе дирижабль с ПРОТИВОСНАРЯДНЫМ бронированием. Да еще способный вести МАНЕВРЕННЫЙ воздушный бой. (Хорошо гуманитариям, они такими вопросами не заморачиваются). Сломал мозг.
Кто-нибудь умеет создавать свитки с заклинанием малого исцеления ? Пришлите два. А то мне еще вот над этим фрагментом думать:
Под ними стояла прялка-колесо, на которою была перекинута незаконченная мастерицей ткань.
Так хочется понять - как они там, в паралельной реальности, мудряются на ПРЯЛКЕ получать не пряжу, а сразу ткань. Но боюсь

Рейтинг: +5 ( 5 за, 0 против).

Linux программирование в примерах (fb2)

- Linux программирование в примерах (пер. Р. Г. Галеев) 2.2 Мб, 706с. (скачать fb2) - Арнольд Роббинс

Настройки текста:



Linux программирование в примерах

Предисловие

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

Рассматривая конкретные программы, вы не только видите, как использовать Linux API, но можете также исследовать реальные проблемы (производительности, переносимости, устойчивости), которые возникают при написании программного обеспечения.

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

Аудитория

Данная книга предназначена для лиц, разбирающихся в программировании и знакомых с основами С, по крайней мере на уровне книги Кернигана и Ричи Программирование на языке С. (Программисты Java, желающие прочесть эту книгу, должны разбираться в указателях С, поскольку С активно их использует.) В примерах используются как версия Стандартного С 1990 года, так и Оригинальный С.

В частности, вам следует быть знакомыми со всеми операторами С, структурами управления потоком исполнения, использованием объявлений переменных и указателей, функциями работы со строками, использованием exit() и набором функций <stdio.h> для файлового ввода/вывода.

Вы должны понимать базовые концепции стандартного ввода, стандартного вывода и стандартной ошибки, а также знать тот факт, что все программы на С получают массив символьных строк, представляющих вызываемые опции и аргументы. Вы должны также быть знакомы с основными инструментами командной строки, такими, как cd, cp, date, ln, ls, maninfo, если он у вас имеется), rmdir и rm, с использованием длинных и коротких опций командной строки, переменных окружения и перенаправления ввода/вывода, включая каналы.

Мы предполагаем, что вы хотите писать программы, которые работают не только под GNU/Linux, но и на множестве различных систем Unix. С этой целью мы помечаем каждый интерфейс с точки зрения его доступности (лишь для систем GLIBC или определен в POSIX и т.д.), а в тексте приведены также советы по переносимости.

Программирование, которое здесь приводится, может быть на более низком уровне, чем вы обычно использовали; это нормально. Системные вызовы являются основными строительными блоками для операций более высокого уровня и поэтому они низкоуровневые по своей природе. Это, в свою очередь, определяет использование нами С: функции API были спроектированы для использования из С, и код, связывающий их с языками более высокого уровня, такими как C++ и Java, неизбежно будет на более низком уровне и вероятнее всего, написанным на С. «Низкий уровень» не означает «плохой», это просто значит «более стимулирующий».

Что вы изучите

Данная книга фокусируется на базовых API, образующих ядро программирования под Linux:

• Управление памятью

• Файловый ввод/вывод

• Метаданные файлов

• Процессы и сигналы

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

• Поддержка программирования (сортировка, анализ аргументов и т.д.)

• Интернационализация

• Отладка

Мы намеренно сохранили список тем коротким. Мы считаем, что попытка научить а одной книге «всему, что можно узнать», пугает. Большинство читателей предпочитают книжки поменьше, более сфокусированные, и лучшие книги по Unix написаны таким способом

Поэтому вместо одного гигантского тома мы планируем несколько книг: одну по межпроцессному взаимодействию (IPC) и сетям, другую по разработке программного обеспечения и переносимости кода. Мы также положили глаз а направлении дополнительных томов в серии Программирование под Linux на примерах, которые будут раскрывать такие темы, как многопоточное программирование и программирование графических интерфейсов пользователя (GUI).

Рассматриваемые нами API включают как системные вызовы, так и библиотечные функции. Действительно, на уровне С оба вида выступают в виде простых вызовов функций. Системный вызов является непосредственным запросом системной службы, такой, как чтение или запись файла или создание процесса. Библиотечная функция, с другой стороны, работает на уровне пользователя, возможно, никогда не запрашивая какие-либо сервисы у операционной системы. Системные вызовы документированы в разделе 2 справочного руководства (которое можно просмотреть с помощью команды man), а библиотечные функции документированы в разделе 3.

Нашей целью является научить вас использовать Linux API на примерах: в частности, посредством использования, где это возможно, как оригинальных исходных кодов Unix, так и инструментов GNU. К сожалению, самодостаточных примеров не так много, как должно было бы быть. Поэтому мы также написали большое число небольших демонстрационных программ. Был сделан акцент на принципах программирования: особенно на таких аспектах программирования для GNU, как «никаких произвольных ограничений», которые превращают инструменты GNU в незаурядные программы.

Выбор для изучения повседневных программ намеренный. Если вы уже использовали GNU/Linux в течение какого-либо периода времени, вы уже понимаете, что делают такие программы, как ls и cp; после этого просто погрузиться прямо в то, как работают программы, не тратя много времени на изучение того, что они делают.

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

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

Наконец, каждая глава завершается упражнениями. Некоторые из них требуют модификации или написания кода. Другие больше относятся к категориям «Мысленных экспериментов» или «как вы думаете, почему…». Мы рекомендуем выполнить их все — они помогут закрепить понимание материала.

Небольшой — значит красивый: программы Unix

Закон Хоара: «Внутри каждой большой программы есть старающаяся пробиться маленькая программа»

- C.A.R. Hoare -

Вначале мы планировали обучать Linux API, используя код инструментов GNU. Однако, современные версии даже простых программ командной строки (подобно mv и cp) большие и многофункциональные. Это особенно верно в отношении GNU вариантов стандартных утилит, которые допускают длинные и короткие опции, делают все, требуемое POSIX и часто имеют также дополнительные, внешне не связанные опции (подобно выделению вывода).

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

Вот когда закон Хоара[1] вдохновил нас на рассмотрение в качестве примера кода оригинальных программ Unix. Оригинальные утилиты V7 Unix маленькие и простые, что упрощает наблюдение происходящего и понимание использования системных вызовов (V7 был выпущен около 1979 г.; это общий предок всех современных систем Unix, включая системы GNU/Linux и BSD.)

В течение многих лет исходный код Unix был защищен авторскими правами и лицензионными соглашениями коммерческой тайны, что затрудняло его использование для обучения и делало невозможным опубликование. Это до сих пор верно в отношении исходного кода всех коммерческих систем Unix. Однако в 2002 г. Caldera (в настоящее время работающая под именем SCO) сделала оригинальный код Unix (вплоть до V7 и 32V Unix) доступным на условиях лицензии в стиле Open Source (см. приложение В «Лицензия Caldera для старой Unix»). Это дает нам возможность включить в эту книгу код из ранних систем Unix.

Стандарты

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

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

Здесь интерес для нас представляют:

1. ISO/IEC International Standard 9899 Programming Languages — С (Международный стандарт ISO/IEC 9899. Языки программирования - С), 1990. Первый официальный стандарт для языка программирования С.

2. ISO/IEC International Standard 9899. Programming Languages — С, Second edition, 1999 (Международный стандарт ISO/IEC 9899. Языки программирования С, второе издание). Второй (текущий) официальный стандарт для языка программирования C.

3. ISO/IEC International Standard 14882. Programming Languages — С++, 1998 (Международный стандарт ISO/IEC 14882. Языки программирования - С++). Первый официальный стандарт для языка программирования С++.

4. ISO/IEC International Standard 14882. Programming Languages — С++, 2003 (Международный стандарт 14882. Языки программирования — С++). Второй (текущий) официальный стандарт для языка программирования С++.

5. IEEE Standard 1003 1-2001 Standard for Information Technology — Portable Operating System Interface (POSIX®) (Стандарт IEEE 1003.1-2001. Стандарт информационных технологий — переносимый интерфейс операционной системы). Текущая версия стандарта POSIX; описывает поведение, ожидаемое от Unix и Unix-подобных систем. Данное издание освещает как системные вызовы, так и библиотечные интерфейсы с точки зрения программиста C/C++, и интерфейс оболочки и инструментов с точки зрения пользователя. Он состоит из нескольких томов:

 • Базовые определения (Base Definitions). Определения терминов, средств и заголовочных файлов.

 • Базовые определения — Обоснование (Base Definitions — Rationale). Объяснения и обоснования выбора средств как включенных, так и невключенных в стандарт.

 • Системные интерфейсы (System Interfaces). Системные вызовы и библиотечные функции. POSIX называет обе разновидности просто «функции».

 • Оболочка и инструменты (Shell and Utilities). Язык оболочки и доступные для интерактивного использования и использования сценариями оболочки инструменты.

Хотя стандарты языков не являются захватывающим чтением, можно рассмотреть покупку экземпляра стандарта С, он дает окончательное определение языка. Книги можно приобрести в ANSI[2] и в ISO[3]. (PDF-версия стандарта С вполне доступна.)

Стандарт POSIX можно заказать в The Open Group[4]. Исследуя в каталоге их изданий элементы, перечисленные а «Спецификациях CAE» («CAE Specifications»), вы можете найти отдельные страницы для каждой части стандарта (озаглавленные с «C031» по «C034»). Каждая такая страница предоставляет свободный доступ к HTML версии определенного тома

Стандарт POSIX предназначен для реализации как Unix и Unix-подобных систем, так и не-Unix систем. Таким образом, базовые возможности, которые он предоставляет, составляют лишь часть возможностей, которые есть на системах Unix. Однако, стандарт POSIX определяет также расширения — дополнительные возможности, например, для многопоточности или поддержки реального времени. Для нас важнее всего расширение X/Open System Interface (XSI), описывающее возможности исторических систем Unix.

По всей книге мы помечаем каждый API в отношении его доступности: ISO С, POSIX, XSI, только GLIBC или как нестандартный, но широко доступный.

Возможности и мощь: программы GNU

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

Что еще важнее, одной из главных свобод, выдвинутых явным образом Фондом бесплатных программ (Free Software Foundation) и проектом GNU[5], является «свобода обучения». Программы GNU предназначены для обеспечения большого собрания хорошо написанных программ, которые программисты среднего уровня могут использовать а качестве источника для своего обучения.

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

Мы считаем, что программное обеспечение GNU лучше, поскольку оно свободно (в смысле «свободы», а не «бесплатного пива»)[6]. Но признается также, что программное обеспечение GNU часто также технически лучше соответствующих двойников в Unix, и мы уделили место в разделе 1.4 «Почему программы GNU лучше», чтобы это объяснить

Часть примеров кода GNU происходит из gawk (GNU awk). Главной причиной этого является то, что это программа, с которой мы очень знакомы, поэтому было просто отобрать оттуда примеры. У нас нет относительно нее других притязаний.

Обзор глав

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

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

Глава 1, «Введение»,

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

Глава 2, «Аргументы, опции и переменные окружения»,

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

Глава 3, «Управление памятью на уровне пользователя»,

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

Глава 4, «Файлы и файловый ввод/вывод»,

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

Глава 5, «Каталоги и служебные данные файлов»,

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

Глава 6, «Общие библиотечные интерфейсы — часть 1»,

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

Глава 7, «Соединяя все вместе: ls»,

связывает воедино все рассмотренное до сих пор, рассматривая программу V7 ls.

Глава 8, «Файловые системы и обходы каталогов»,

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

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

Глава 9, «Управление процессами и каналы»,

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

Глава 10, «Сигналы»,

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

Глава 11, «Права доступа и ID пользователей и групп»,

рассматривает, как идентифицируются процессы и файлы, как работает проверка прав доступа и как работают механизмы setuid и setgid.

Глава 12, «Общие библиотечные интерфейсы — часть 2»,

рассматривает оставшуюся часть общих API; многие из них более специализированы, чем первый общий набор API.

Глава 13, «Интернационализация и локализация»,

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

Глава 14, «Расширенные интерфейсы»,

описывает несколько расширенных версий интерфейсов, освещенных в предыдущих главах, а также более подробно освещает блокировку файлов.

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

Глава 15, «Отладка»,

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

Глава 16, «Проект, связывающий все воедино»,

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

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

Приложение А, «Научитесь программированию за десять лет»,

ссылается на знаменитое высказывание: «Москва не сразу строилась»[7]. Также и квалификация в Linux/Unix и понимание этих систем приходит лишь со временем и практикой. С этой целью мы включили это эссе Петера Норвига, которое мы горячо рекомендуем.

Приложение В, «Лицензия Caldera для старой Unix»,

охватывает исходный код Unix, использованный в данной книге.

Приложение С, «Общедоступная лицензия GNU»,

охватывает исходный код GNU, использованный в данной книге.

Соглашения об обозначениях

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

Вещи, находящиеся на компьютере, обозначаются моноширинными шрифтом, как в случае имен файлов (foo.c) и названий команд (ls, grep). Короткие фрагменты, которые вы вводите, дополнительно заключаются в одинарные кавычки: 'ls -l *.с'

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

$ ls -1 /* Просмотр файлов. Опция - цифра 1, а не буква l */

foo

bar

baz

Мы предпочитаем оболочку Борна и ее варианты (ksh93, Bash) по сравнению с оболочкой С; соответственно на всех наших примерах показана лишь оболочка Борна. Знайте, что правила применения кавычек и переноса на следующую строку в оболочке С другие; если вы используете ее, то на свой страх и риск![8]

При ссылках на функции в программах мы добавляем к имени функции пустую пару скобок: printf(), strcpy(). При ссылке на справочную страницу (доступную по команде man), мы следуем стандартному соглашению Unix по написанию имени команды или функции курсивом, а раздела — в скобках после имени обычным шрифтом: awk(1), printf(3)[9].

Где получить исходные коды Unix и GNU

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

Код Unix

Архивы различных «древних» версий Unix поддерживаются Обществом наследства UNIX (The UNIX Heritage Society — TUHS), http://www.tuhs.org.

Наибольший интерес представляет возможность просматривать архив старых исходных кодов Unix через веб. Начните с http://minnie.tuhs.org/UnixTree/. Все примеры кода в данной книге из седьмого издания исследовательской системы UNIX, известной также как «V7».

Сайт TUHS физически расположен в Австралии, хотя имеются зеркала архива по всему миру — см. http://www.tuhs.org/archive_sites.html. Эта страница также указывает, что архив доступен для зеркала через rsync. (Если у вас нет rsync, см. http://rsync.samba.org/: это стандартная утилита на системах GNU/Linux.)

Чтобы скопировать весь архив, потребуется примерно 2-3 гигабайта дискового пространства. Для копирования архива создайте пустой каталог, а в нем выполните следующие команды:

mkdir Applications 4BSD PDP-11 PDP-11/Trees VAX Other

rsync -avz minnie.tuhs.org::UA_Root .

rsync -avz minnie.tuhs.org::UA_Applications Applications

rsync -avz minnie.tuhs.org::UA_4BSD 4BSD

rsync -avz minnie.tuhs.org::UA_PDP11 PDP-11

rsync -avz minnie.tuhs.org::UA_PDP11_Trees PDP-11/Trees

rsync -avz minnie.tuhs.org::UA_VAX VAX

rsync -avz minnie.tuhs.org::UA_Other Other

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

В рассылке TUHS можно также поинтересоваться, нет ли поблизости от вас кого-нибудь, кто мог бы предоставить вам архив на CD-ROM, чтобы избежать пересылки по Интернету такого большого количества данных.

Группа в Southern Storm Software, Pty. Ltd. в Австралии «модернизировала» часть кода уровня пользователя V7, так что его можно откомпилировать и запустить на современных системах, особенно на GNU/Linux. Этот код можно загрузить с их веб-сайта[10].

Интересно отметить, что код V7 не содержит в себе каких-либо уведомлений об авторских правах или разрешениях. Авторы писали код главным образом для себя и своего исследования, оставив проблемы разрешений отделу корпоративного лицензирования AT&T.

Код GNU

Если вы используете GNU/Linux, ваш дистрибутив поступит с исходным кодом, предположительно в формате, используемом для упаковки (файлы RPM Red Hat, файлы DEB Debian, файлы .tar.gz Slackware и т.д.) Многие примеры в книге взяты из GNU Coreutils, версия 5.0. Найдите соответствующий CD-ROM для своего дистрибутива GNU/Linux и используйте для извлечения кода соответствующий инструмент. Или следуйте для получения кода инструкциям в следующих нескольких абзацах.

Если вы предпочитаете самостоятельно получать файлы из ftp-сайта GNU, вы найдете его по адресу: ftp://ftp.gnu.org/gnu/coreutils/coreutils-5.0.tar.gz.

Для получения файла можно использовать утилиту wget:

$ wget ftp://ftp.gnu.org/ena/coreutils/coreuitils-5.0.tar.gz

/* Получить дистрибутив */

/* ... здесь при получении файла куча вывода ... */

В качестве альтернативы можно использовать для получения файла старый добрый ftp:

$ ftp ftp.gnu.org /* Подключиться к ftp-сайту GNU */

Connected to ftp.gnu.org (199.232.41.7).

220 GNU FTP server ready.

Name (ftp.gnu.org:arnold): anonymous /* Использовать анонимный ftp */

331 Please specify the password.

Password: /* Пароль на экране не отображается */

230-If you have any problems with the GNU software or its downloading,

230-please refer your questions to <gnu@gnu.org>.

... /* Куча вывода опущена */

230 Login successful. Have fun.

Remote system type is UNIX.

Using binary mode to transfer files.

ftp> cd /gnu/coreutils /* Перейти в каталог Coreutils */

250 Directory successfully changed.

ftp> bin

200 Switching to Binary mode.

ftp> hash /* Выводить символы # по мере закачки */

Hash mark printing on (1024 bytes/hash mark).

ftp> get coreutils-5.0.tar.gz /* Retrieve file */

local: coreutils-5.0.tar.gz

remote: coreutils-5.0.tar.gz

227 Entering Passive Mode (199,232,41,7,86,107)

150 Opening BINARY mode data connection for coreutils-5.0.tar.gz (6020616 bytes)

######################################################################

######################################################################

...

226 File send OK.

6020616 bytes received in 2.03e+03 secs (2.9 Kbytes/sec)

ftp> quit /* Закончить работу */

221 Goodbye.

Получив файл, извлеките его следующим образом:

$ gzip -dc < coreutils-5.0.tar.gz | tar -xvpf - /* Извлечь файлы */

/* ... при извлечении файла куча вывода ... */

Системы, использующие GNU tar, могут использовать следующее заклинание:

$ tar -xvpzf coreutils-5.0.tar.gz /* Извлечь файлы */

/* ... при извлечении файла куча вывода ... */

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

Файл Coreutils 5.0 Даты авторского права
lib/safe-read.с © 1993-1994, 1998, 2002
lib/safe-write.c © 2002
lib/utime.c © 1998, 2001-2002
lib/xreadlink.с © 2001
src/du.c © 1988-1991, 1995-2003
src/env.с © 1986, 1991-2003
src/install.с © 1989-1991, 1995-2002
src/link.c © 2001-2002
src/ls.с © 1985, 1988, 1990, 1991, 1995-2003
src/pathchk.c © 1991-2003
src/sort.с © 1988, 1991-2002
src/sys2.h © 1997-2003
src/wc.с © 1985, 1991, 1995-2002
Файл Gawk 3.0.6 Даты авторского права
eval.с © 1986, 1988, 1989, 1991-2000
Файл Gawk 3.1.3 Даты авторского права
awk.h © 1986, 1988, 1989, 1991-2003
builtin.с © 1986, 1988, 1989, 1991-2003
eval.с © 1986, 1988, 1989, 1991-2003
io.c © 1986, 1988, 1989, 1991-2003
main.с © 1986, 1988, 1989, 1991-2003
posix/gawkmisc.с © 1986, 1988, 1989, 1991-1998, 2001-2003
Файл Gawk 3.1.4 Даты авторского права
builtin.c © 1986, 1988, 1989, 1991-2004
Файл GLIBC 23.2 Даты авторского права
locale/locale.h © 1991, 1992, 1995-2002
posix/unistd.h © 1991-2003
time/sys/time.h © 1991-1994, 1996-2003
Файл Make 3.80 Даты авторского права
read.с © 1988-1997, 2002
Где получить примеры программ, использованные в данной книге

Примеры программ, использованные в данной книге, можно найти по адресу: http://authors.phptr.com/robbins.

Об обложке

«Это оружие Джедая …, элегантное оружие для более цивилизованной эпохи. На протяжении тысяч поколений Рыцари Джедай были защитниками мира и справедливости в Старой Республике. От мрачных времен, до Империи».

- Оби-Ван Кеноби -

Возможно, вы удивляетесь, почему мы поместили на обложке легкую саблю и использовали ее во внутреннем оформлении книги. Что она представляет и какое она имеет отношение к программированию под Linux?

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

Элегантность легкой сабли отражает элегантность оригинального дизайна Unix API. Там также обдуманное, точное использование API и программных инструментов и принципов проектирования GNU привело к сегодняшним мощным, гибким, развитым системам GNU/Linux. Эта система демонстрирует знание и понимание программистов, создавших все их компоненты.

И конечно, легкие сабли — это просто круто!

Благодарности

Написание книги требует большого количества работы, а чтобы сделать это хорошо, нужна помощь от многих людей. Д-р Brian W. Kernighan, д-р Doug McIlroy, Peter Memishian и Peter van der Linden сделали рецензию первоначального предложения. David J. Agans, Fred Fish, Don Marti, Jim Meyering, Peter Norvig и Julian Seward достали разрешения на воспроизведение различных элементов, процитированных по всей книге. Спасибо Geoff Collyer, Ulrich Drepper, Yosef Gold, д-ру C.A.R. (Tony) Hoare, д-ру Manny Lehman, Jim Meyering, д-ру Dennis M. Ritchie, Julian Seward, Henry Spencer и д-ру Wladyslaw M. Turski за предоставление множества полезной общей информации. Спасибо также другим членам группы GNITS. Karl Berry, Akim DeMaille, Ulrich Drepper, Greg McGary, Jim Meyering, Francois Pinard и Tom Tromey, которые предоставили полезную обратную связь относительно хорошей практики программирования. Karl Berry, Alper Ersoy и д-р Nelson H.F. Beebe предоставили ценную техническую помощь по Texinfo и DocBook/XML.

Хорошие технические обзоры не только гарантируют, что автор использует правильные факты, они также гарантируют, что он тщательно обдумывает свое представление. Д-р Nelson H.F. Beebe, Geoff Collyer, Russ Cox, Ulrich Drepper, Randy Lechlitner, д-р Brian W. Kernighan, Peter Memishian, Jim Meyering, Chet Ramey и Louis Taber работали в качестве технических рецензентов для всей книги. Д-р Michael Brennan предоставил полезные комментарии для главы 15. Их рецензии принесли пользу как содержанию, так и многим примерам программ. Настоящим я благодарю их всех. Как обычно говорят в таких случаях большинство авторов, «все оставшиеся ошибки мои».

Я особенно хотел бы поблагодарить Mark Taub из Pearson Education за инициирование этого проекта, за его энтузиазм для этой серии и за его помощь и советы по мере прохождения книги через различные ее стадии. Anthony Gemmellaro сделал феноменальную работу по реализации моей идеи для обложки, а внутренний дизайн Gail Cocker великолепен. Faye Gemmellaro сделал процесс производства вместо рутины приятным. Dmitry Kirsanov и Alina Kirsanova сделали рисунки, макеты страниц и предметный указатель; работать с ними было одно удовольствие.

Наконец, моя глубочайшая благодарность жене Мириам за ее поддержку и ободрение во время написания книги.

Арнольд Роббинс
Nof Ayalon
ИЗРАИЛЬ

Часть 1 Файлы и пользователи

Глава 1 Введение

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

Далее, поскольку мы будем изучать код в обеих стилях, мы кратко рассмотрим главные различия между стандартным С 1990 г. и первоначальным С. Наконец, мы довольно подробно обсудим то, что делает GNU-программы «лучше» — принципы программирования, использование которых в коде мы увидим.

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

1.1. Модель файловой системы Linux/Unix

Одной из движущих целей первоначального проекта 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 — сменить владельца)[11].

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

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

Unix и Linux поддерживают понятие суперпользователя (superuser): это пользователь с особыми привилегиями. Этот пользователь известен как root и имеет UID, равный 0. root позволено делать все; никаких проверок, все двери открыты, все ящики отперты.[13] (Это может иметь важные последствия для безопасности, которых мы будем касаться по всей книге, но не будем освещать исчерпывающе.) Поэтому, даже если файл имеет режим ----------, 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 было объединение файлового ввода- вывода и ввода-вывода от устройств.[14] Устройства выглядят в файловой системе как файлы, для доступа к ним используются обычные права доступа, а для их открытия, чтения, записи и закрытия используются те же самые системные вызовы ввода-вывода. Вся «магия», заставляющая устройства выглядеть подобно файлам, скрыта в ядре. Это просто другой аспект движущего принципа простоты в действии, мы можем выразить это как никаких частных случаев для кода пользователя.

В повседневной практике, в частности, на уровне оболочки, часто появляются два устройства: /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, «Получение информации о файлах».

1.2. Модель процессов Linux/Unix

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.3. Стандартный С против оригинального С

В течение многих лет определение С де-факто можно было найти в первом издании книги Брайана Кернигана и Денниса Ричи «Язык программирования С» (Brian Kernighan & Dennis Ritchie, The С Programming Language). Эта книга описала С, как он существовал для Unix и на системах, на которые его перенесли разработчики лаборатории Bell Labs. На протяжении данной книги мы называем его как «оригинальный С», хотя обычным является также название «С Кернигана и Ричи» («K&R С»), по именам двух авторов книги. (Деннис Ричи разработал и реализовал С.)

Стандарт ISO С 1990 г.[17] формализовал определения языка, включая функции библиотеки С (такие, как printf() и fopen()). Комитет по стандартам С проделал замечательную работу по стандартизации существующей практики и избежал введения новых возможностей, с одним значительным исключением (и несколькими незначительными). Наиболее заметным изменением языка было использование прототипов функций, заимствованных от С++.

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

Объявление

extern int myfunc(struct my_struct *a,

 struct my_struct *b, double c, int d);

Определение

int myfunc(struct my_struct *a,

 struct my_struct *b, double c, int d) {

 ...

}

...

struct my_struct s, t;

int j;

...

/* Вызов функции, где-то в другом месте: */

j = my_func(&s, &t, 3.1415, 42);

Это правильный вызов функции. Но рассмотрите ошибочный вызов:

j = my_func(-1, -2, 0);

/* Ошибочные число и типы аргументов */

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

extern int myfunc();

/* Возвращает int, аргументы неизвестны */

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

myfunc(a, b, с, d); /* Возвращаемый тип int*/

struct my_struct *а, *b;

double с;

/* Обратите внимание, нет объявления параметра d*/

{

 ...

}

Рассмотрите снова тот же ошибочный вызов функции: 'j = my_func(-1, -2 , 0);'. В оригинальном С у компилятора нет возможности узнать, что вы (ошибочно, полагаем) передали my_func() ошибочные аргументы. Подобные ошибочные вызовы обычно приводят к трудно устранимым проблемам времени исполнения (таким, как ошибки сегментации, из-за чего программа завершается), и для работы с такими вещами была создана программа Unix lint.

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

Для С стандарта 1990 г. код, написанный в оригинальном стиле, является действительным как для объявлений, так и для определений. Это дает возможность продолжать компилировать миллионы строк существующего кода с помощью компилятора, удовлетворяющего стандарту. Новый код, очевидно, должен быть написан с прототипами из-за улучшенных возможностей проверки ошибок времени компилирования.

Стандарт С 1999 г.[18] продолжает допускать объявления и определения в оригинальном стиле. Однако, правило «неявного int» было убрано; функции должны иметь возвращаемый тип, а все параметры должны быть объявлены.

Более того, когда программа вызывала функцию, которая не была формально объявлена, оригинальный С создал бы для функции неявное объявление с возвращаемым типом int. С стандарта 1999 г. делал то же самое, дополнительно отметив, что у него не было информации о параметрах. С стандарта 1999 г. не предоставляет больше возможности «автоматического объявления».

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

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

Хотя стандарт С 1999 г. добавляет некоторые дополнительные ключевые слова и возможности, отсутствующие в версии 1990 г., мы решили придерживаться диалекта 1990 г, поскольку компиляторы C99 не являются пока типичными. Практически, это не имеет значения: код C89 должен компилироваться и запускаться без изменений при использовании компилятора C99, а новые возможности C99 не затрагивают наше обсуждение или использование фундаментальных API Linux/Unix.

1.4. Почему программы GNU лучше

Что делает программу GNU программой GNU?[19] Что делает программное обеспечение 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 С[20]. Но поскольку ядро еще не завершено, и пользователи используют инструменты 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[21], мы чувствуем, что при модификации некоторых других программ, придерживание уже использованного стиля кода является исключительно важным. Последовательность в стиле кода более важна, чем сам стиль, который вы выбираете. 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.[22]

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

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

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

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

Наконец, мы цитируем главу 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.

1.5. Пересмотренная переносимость

Переносимость является чем-то вроде Святого Грааля; всегда недостающим впоследствии, но не всегда достижимым и определенно нелегким. Есть несколько аспектов написания переносимого кода. GNU Coding Standards обсуждает многие из них. Но есть и другие стороны. При разработке принимайте переносимость во внимание как на высоком, так и на низком уровнях. Мы рекомендуем следующие правила:

Соответствуйте стандартам

Хотя это может потребовать напряжения, знакомство с формальными стандартами языка, который вы используете, окупается. В частности, обратите внимание на стандарты ISO 1990 и 1999 гг. для С и стандарт 2003 г. для С++, поскольку большинство программ Linux создано на одном из этих двух языков.

В промышленности также широко поддерживается стандарт POSIX для интерфейса библиотечных и системных вызовов, хотя он и большой. Написание в соответствии с POSIX значительно повышает шансы успешного переноса вашего кода и на другие системы, помимо GNU/Linux. Этот стандарт вполне читабелен; он концентрирует в себе десятилетия опыта и хорошей практики.

Выбирайте для работы лучший интерфейс

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

Изолируйте проблемы переносимости за новыми интерфейсами

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

Используйте для конфигурирования Autoconf

По возможности избегайте #ifdef. Если это невозможно, скройте его в низкоуровневом библиотечном коде. Для проверки тестов, которые должны исполняться с помощью #ifdef, используйте Autoconf.

1.6. Рекомендуемая литература

1. The С Programming Language, 2nd edition, by Brian W. Kernighan and Dennis M. Ritchie Prentice-Hall, Englewood Cliffs, New Jersey, USA, 1989. ISBN: 0-13-110370-9[25].

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

2. С, A Reference Manual. 5th edition, by Samuel P. Harbison III and Guy L. Steele, Ji. Prentice-Hall, Upper Saddle River, New Jersey, USA, 2002. ISBN: 0-13-089592-X.

Это тоже классическая книга. Она охватывает оригинальный С, а также стандарты 1990 и 1999 гг. Поскольку она современна, она служит ценным дополнением к первой книге. Она охватывает многие важные темы, такие, как интернациональные типы и библиотечные функции, которых нет в книге Кернигана и Ричи.

3. Notes on Programming in С, by Rob Pike, February 21,1989 Доступна через множество веб-сайтов. Возможно, чаще всего упоминаемым местом является http://www.lysator.liu.se/c/pikestyle.html. (Многие другие полезные статьи доступны там же на один уровень выше: http://www.lysator.liu.se/с/.) Роб Пайк много лет работал в исследовательском центре Bell Labs, где были созданы С и Unix, и проводил там изыскания. Его замечания концентрируют многолетний опыт в «философию ясности в программировании», это стоит прочтения.

4. Различные ссылки на http://www.chris-lott.org/resources/cstyle/. Этот сайт включает заметки Роба Пайка и несколько статей Генри Спенсера (Henry Spencer). Особенно высокое положение занимает «Рекомендуемый стиль С и стандарты программирования» (Recommended С Style and Coding Standards), первоначально написанный на сайте Bell Labs Indian Hill.

1.7. Резюме

• «Файлы и процессы» суммируют мировоззрение Linux/Unix. Трактовка файлов как потоков байтов, а устройств как файлов, и использование стандартных ввода, вывода и ошибки упрощают построение программ и унифицируют модель доступа к данным. Модель прав доступа проста, но гибка, и приложима как к файлам, так и каталогам.

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

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

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

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

Упражнения

1. Прочтите и прокомментируйте статью Ричарда М. Столмена «Проект GNU» (Richard M. Stallman, «The GNU Project»)[26], первоначально написанную в августе 1998 г.

Глава 2 Аргументы, опции и переменные окружения

Первой задачей любой программы обычно является интерпретация опций и аргументов командной строки. Данная глава рассматривает, как программы С (и С++) получают аргументы своей командной строки, описывает стандартные процедуры для разбора опций и бросает взгляд на переменные окружения.

2.1. Соглашения по опциям и аргументам

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

$ ls main.с opts.с process.с

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

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

2.2. Базовая обработка командной строки

Программа на С получает доступ к своим аргументам командной строки через параметры 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, завершающий символ новой строки опускается. (Это используется для приглашений из сценариев оболочки.) Вот код[28]:

1  #include <stdio.h>

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<argc; 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. Мы решили оставить использующий это слово код, как есть, но вы должны знать, что оно больше не имеет реального применения.[29]

2.3. Разбор опций: getopt() и getopt_long()

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

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

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

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

#include <unistd.h> /*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. Длинные опции

Функция getopt_long() осуществляет разбор длинных опций в описанном ранее виде. Дополнительная процедура getopt_long_only() работает идентичным образом, но она используется для программ, в которых все опции являются длинными и начинаются с единичного символа '-'. В остальных случаях обе функции работают точно так же, как более простая функция GNU getopt(). (Для краткости, везде, где мы говорим «getopt_long()», можно было бы сказать «getopt_long() и getopt_long_only()».) Вот объявления функций из справки getopt(3) GNU/Linux:

#include <getopt.h> /* GLIBC */


int getopt_long(int argc, char *const argv[],

 const char *optstring,

 const struct option *longopts, int *longindex);

int getopt_long_only(int argc, char *const argv[],

 const char *optstring,

 const struct option *longopts, int *longindex);

Первые три аргумента те же, что и в getopt(). Следующая опция является указателем на массив struct option, который мы назовем таблицей длинных опций и который вскоре опишем. Параметр longindex, если он не установлен в NULL, указывает на переменную, в которую помешается индекс обнаруженной длинной опции в longopts. Это полезно, например, при диагностике ошибок.

2.3.3.1. Таблица длинных опций

Длинные опции описываются с помощью массива структур struct option. Структура struct option определена в <getopt.h>; она выглядит следующим образом:

struct option {

 const char *name;

 int has_arg;

 int *flag;

 int val;

};

Элементы структуры следующие:

const char *name

Это имя опции без предшествующих черточек, например, «help» или «verbose».

int has_arg

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

int *flag

Если этот указатель равен NULL, getopt_long() возвращает значение поля val структуры. Если он не равен NULL, переменная, на которую он указывает, заполняется значением val, a getopt_long() возвращает 0. Если flag не равен NULL, но длинная опция отсутствует, указанная переменная не изменяется.

int val

Если длинная опция обнаружена, это возвращаемое значение или значение для загрузки в *flag, если flag не равен NULL. Обычно, если flag не равен NULL, val является значением true/false, вроде 1 или 0. С другой стороны, если flag равен NULL, val обычно содержит некоторую символьную константу. Если длинная опция соответствует короткой, эта символьная константа должна быть той же самой, которая появляется в аргументе optstring для этой опции. (Все это станет вскоре ясно, когда мы рассмотрим несколько примеров.)


Таблица 2.1. Значения для has_arg

Макроподстановка Числовое значение Смысл
no_argument 0 Опция не принимает аргумент
required_argument 1 Опции требуется аргумент
optional_argument 2 Аргумент опции является необязательным

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

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

while ((с = getopt(argc, argv, ":af:hv")) != -1) {

 switch (с) {

 case 'a':

  do_all = 1;

  break;

 case 'f':

  myfile = optarg;

  break;

 case 'h':

  do_help = 1;

  break;

 case 'v':

  do_verbose = 1;

  break;

 ... /* Здесь обработка ошибок */

 }

}

Когда flag не равен NULL, getopt_long() устанавливает значения переменных за вас. Это снижает число операторов case в предыдущем switch с трех до одного. Вот пример таблицы длинных опций и код для работы с ней:

int do_all, do_help, do_verbose; /* флаговые переменные */

char *my_file;

struct option longopts[] = {

 { "all", no_argument, &do_all, 1 },

 { "file", required_argument, NULL, 'f' },

 { "help", no_argument, &do_help, 1 },

 { "verbose", no_argument, &do_verbose, 1 },

 { 0, 0, 0, 0 }

};


while ((с =

 getopt_long(argc, argv, ":f:", longopts, NULL)) != -1) {

 switch (c) {

 case 'f':

  myfile = optarg;

  break;

 case 0:

  /* getopt_long() устанавливает значение переменной,

     просто продолжить выполнение */

  break;

 ... /* Здесь обработка ошибок */

 }

}

Обратите внимание, что значение, переданное аргументу optstring, не содержит больше 'a', 'h' или 'v'. Это означает, что соответствующие короткие опции неприемлемы. Чтобы разрешить как длинные, так и короткие опции, вам придется восстановить в switch соответствующие case из первого примера.

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

2.3.3.2. Длинные опции в стиле POSIX

Стандарт POSIX резервирует опцию -W для специфических для производителя возможностей. Поэтому по определению -W непереносимо между различными системами.

Если за W в аргументе optstring следует точка с запятой (обратите внимание не двоеточие), getopt_long() рассматривает -Wlongopt так же, как --longopt. Соответственно в предыдущем примере измените вызов следующим образом:

while ((с =

 getopt_long(argc, argv, ":f:W;", longopts, NULL)) != -1) {

С этим изменением -Wall является тем же, что и --all, a -Wfile=myfile тем же, что --file=myfile. Использование точки с запятой позволяет программе использовать при желании -W в качестве обычной опции. (Например, GCC использует ее как нормальную опцию, тогда как gawk использует ее для совместимости с POSIX.)

2.3.3 3. Сводка возвращаемых значений getopt_long()

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


Таблица 2.2. Возвращаемые значения getopt_long()

Возвращаемый код Значение
0 getopt_long() установила флаг, как указано в таблице длинных опций
1 optarg указывает на простой аргумент командной строки
'?' Недействительная опция
' ' Отсутствующий аргумент опции
'x' Символ опции 'x'
-1 Конец опций

Наконец, мы улучшим предыдущий пример кода, показав оператор switch полностью:

int do_all, do_help, do_verbose; /* флаговые переменные */

char *myfile, *user; /* файл ввода, имя пользователя */

struct option longopts[] = {

 { "all", no_argument, &do_all, 1 },

 { "file", required_argument, NULL, 'f'},

 { "help", no_argument, &do_help, 1 },

 { "verbose", no_argument, &do_verbose, 1 },

 { "user" , optional_argument, NULL, 'u'},

 { 0, 0, 0, 0 }

};

...

while((c=getopt_long(argc, argv, ":ahvf:u::W;", longopts, NULL)) != -1) {

 switch (c) {

 case 'a':

  do_all = 1;

  break;

 case 'f':

  myfile = optarg;

  break;

 case 'h':

  do_help = 1;

  break;

 case 'u':

  if (optarg != NULL)

   user = optarg;

  else

   user = "root";

  break;

 case 'v':

  do_verbose = 1;

  break;

 case 0:

  /* getopt_long() установил переменную, просто продолжить */

  break;

#if 0

 case 1:

  /*

   * Используйте этот case, если getopt_long() должна

   * просмотреть все аргументы. В этом случае добавьте к

   * optstring ведущий * символ '-'. Действительный код,

   * если он есть, работает здесь.

   */

  break;

#endif

 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;

 }

}

В своих программах вы можете захотеть сделать для каждого символа опции комментарии, объясняющие их значение. Однако, если вы использовали описательные имена переменных для каждого символа опции, комментарии уже не так нужны. (Сравните do_verbose и vflag.)

2.3.3.4. GNU getopt() или getopt_long() в программах пользователей

Вы можете захотеть использовать в своих программах GNU getopt() или getopt_long() и заставить их работать на не-Linux системах/ Это нормально; просто скопируйте исходные файлы из программы GNU или из CVS архива библиотеки С GNU (GLIBC)[30]. Исходные файлы getopt.h, getopt.с и getopt1.c. Они лицензированы на условиях меньшей общедоступной лицензии (Lesser General Public License) GNU, которая позволяет включать библиотечные функции даже в патентованные программы. Вы должны включить в свою программу копию файла COPYING.LIB наряду с файлами getopt.h, getopt.с и getopt1.с.

Включите исходные файлы в свой дистрибутив и откомпилируйте их с другими исходными файлами. В исходном коде, вызывающем getopt_long(), используйте '#include <getopt.h>', а не '#include "getopt.h"'. Затем, при компилировании, добавьте к командной строке компилятора С -I. Таким способом сначала будет найдена локальная копия заголовочного файла.

Вы можете поинтересоваться: «Вот так, я уже использую GNU/Linux. Почему я должен включать getopt_long() в свой исполняемый модуль, увеличивая его размер, если процедура уже находится в библиотеке С?» Это хороший вопрос. Однако, здесь не о чем беспокоиться. Исходный код построен так, что если он компилируется на системе, которая использует GLIBC, откомпилированные файлы не будут содержать никакого кода! Вот подтверждение на нашей системе:

$ uname -а /* Показать имя и тип системы */

Linux example 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux

$ ls -l getopt.о getopt1.о /* Показать размеры файлов */

-rw-r--r-- 1 arnold devel 9836 Mar 24 13:55 getopt.о

-rw-r--r-- 1 arnold devel 10324 Mar 24 13:55 getopt1.о

$ size getopt.о getopt1.о /* Показать включенные в исполняемый

модуль размеры */

text data bss dec hex filename

0 0 0 0 0 getopt.о

0 0 0 0 0 getopt1.о

Команда size печатает размеры различных составных частей двоичного объекта или исполняемого файла. Мы объясним вывод в разделе 3.1 «Адресное пространство Linux/Unix». Что важно понять прямо сейчас, это то, что несмотря на ненулевой размер самих файлов, они не вносят никакого вклада в конечный исполняемый модуль. (Думаем, это достаточно ясно.)

2.4. Переменные окружения

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

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

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

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

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

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

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

#include <stdlib.h>


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 <stdio.h>


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, отображает

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

Об ошибках сообщайте в <bug-coreutils@gnu.org>. */

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

$ 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 <config.h>

81  #include <stdio.h>

82  #include <getopt.h>

83  #include <sys/types.h>

84  #include <getopt.h>

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 означает, что файл существует, но была какая-то другая ошибка.

2.5. Резюме

• Программы на С получают аргументы своей командной строки через параметры argc и argv. Функция getopt() предоставляет стандартный способ для последовательного разбора опций и их аргументов GNU версия getopt() предоставляет некоторые расширения, a getopt_long() и getopt_long_only() дает возможность легкого разбора длинных опций.

• Окружение представляет собой набор пар 'имя=значение', который каждая программа наследует от своего родителя. Программы могут по прихоти своего автора использовать для изменения своего поведения переменные окружения, в дополнение к любым аргументам командной строки. Для получения значений переменных окружения, изменения их значений или удаления существуют стандартные процедуры (getenv(), setenv(), putenv() и unsetenv()). При необходимости можно получить доступ ко всему окружению через внешнюю переменную environ или через третий аргумент char **envp функции main(). Последний способ не рекомендуется.

Упражнения

1. Предположим, что программа принимает опции -a, -b и , и что -b требует наличия аргумента. Напишите для этой программы код ручного разбора аргументов без использования getopt() или getopt_long(). Для завершения обработки опций принимается --. Убедитесь, что -ас работает, также, как -bYANKEES, -b YANKEES и -abYANKEES. Протестируйте программу.

2. Реализуйте getopt(). Для первой версии вы можете не беспокоиться насчет случая 'optstring[0] == ':''. Можете также игнорировать opterr.

3. Добавьте код для 'optstring[0] == ':'' и opterr к своей версии getopt().

4. Распечатайте и прочтите файлы GNU getopt.h, getopt.с и getopt1.с.

5. Напишите программу, которая объявляет как environ, так и envp, и сравните их значения.

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

 • библиотека анализа аргументов Plan 9 From Bell Labs arg(2)[31],

 • Argp[32],

 • Argv[33],

 • Autoopts[34],

 • GNU Gengetopt[35],

 • Opt[36],

 • Popt[37]. См. также справочную страницу popt(3) системы GNU/Linux.

7. Дополнительный балл, почему компилятор С не может полностью игнорировать ключевое слово register? Подсказка: какие действия невозможно совершать с регистровой переменной?

Глава 3 Управление памятью на уровне пользователя

Без памяти для хранения данных программа не может выполнить никакую работу (Или, скорее, невозможно выполнить никакую полезную работу.) Реальные программы не могут позволить себе полагаться на буферы и массивы структур данных фиксированного размера. Они должны быть способны обрабатывать вводимые данные различных размеров, от незначительных до больших. Это, в свою очередь, ведет к использованию динамически выделяемой памяти — памяти, выделяемой в ходе исполнения, а не при компиляции. Вот как вводится в действие принцип GNU «никаких произвольных ограничений».

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

3.1. Адресное пространство Linux/Unix

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

Код

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

Инициализированные данные

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

Инициализированные нулями данные[38]

Глобальные и статически выделенные данные, которые по умолчанию инициализированы нулями, хранятся в области процесса, который называют областью BSS[39]. У каждого процесса, в котором запущена одна и та же программа, своя область BSS. При запуске данные BSS помещаются в сегмент данных. В исполняемом файле они хранятся в секции BSS.

Формат исполняемого файла Linux/Unix таков, что пространство исполняемого файла на диске занимают лишь переменные, инициализированные ненулевыми значениями. Поэтому большой массив, объявленный как 'static char somebuf[2048];', который автоматически заполняется нулями, не занимает 2 Кб пространства на диске. (Некоторые компиляторы имеют опции, позволяющие вам помещать инициализированные нулями данные в сегмент данных.)

Куча (heap)

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

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

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

Стек

Сегмент стека — это область, в которой выделяются локальные переменные. Локальными являются все переменные, объявленные внутри левой открывающей фигурной скобки тела функции (или другой левой фигурной скобки) и не имеющие ключевого слова static.

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

Рис. 3.1. Адресное пространство Linux/Unix

Хотя перекрывание стека и кучи теоретически возможно, операционная система предотвращает этот случай, и любая программа, пытающаяся это сделать, напрашивается на неприятности. Это особенно верно для современных систем, в которых адресные пространства большие и интервал между верхушкой стека и концом кучи значителен. Различные области памяти могут иметь различную установленную на память аппаратную защиту. Например, сегмент текста может быть помечен «только для исполнения», тогда как у сегментов данных и стека разрешение на исполнение может отсутствовать. Такая практика может предотвратить различные виды атак на безопасность. Подробности, конечно, специфичны для оборудования и операционной системы, и они могут со временем меняться. Стоит заметить, что стандартные как С, так и C++ позволяют размещать элементы с атрибутом const в памяти только для чтения. Сводка взаимоотношений различных сегментов приведена в табл. 3.1.


Таблица 3.1. Сегменты исполняемой программы и их размещение

Память программы Сегмент адресного пространства Секция исполняемого файла
Код Text Text
Инициализированные данные Data Data
BSS Data BSS
Куча Data
Стек Stack

Программа size распечатывает размеры в байтах каждой из секций text, data и BSS вместе с общим размером в десятичном и шестнадцатеричном виде. (Программа ch03-memaddr.с показана далее в этой главе; см. раздел 3.2.5 «Исследование адресного пространства».)

$ cc -o ch03-memaddr.с -о ch03-memaddr /* Компилировать программу */

$ ls -l ch03-memaddr /* Показать общий размер */

-rwxr-xr-x 1 arnold devel 12320 Nov 24 16:45 ch03-memaddr

$ size ch03-memaddr /* Показать размеры компонентов */

text data bss dec  hex filename

1458 276  8   1742 6ce ch03-memaddr


$ strip ch03-memaddr /* Удалить символы */

$ ls -l ch03-memaddr /* Снова показать общий размер */

-rwxr-xr-x 1 arnold devel 3480 Nov 24 16:45 ch03-memaddr

$ size ch03-memaddr /* Размеры компонентов не изменились */

text data bss dec  hex filename

1458 276  8   1742 6ce ch03-memaddr

Общий размер загруженного в память из файла в 12 320 байтов всего лишь 1742 байта. Большую часть этого места занимают символы (symbols), список имен переменных и функций программы. (Символы не загружаются в память при запуске программы.) Программа strip удаляет символы из объектного файла. Для большой программы это может сохранить значительное дисковое пространство ценой невозможности отладки дампа ядра[40], если таковой появится (На современных системах об этом не стоит беспокоиться, не используйте strip.) Даже после удаления символов файл все еще больше, чем загруженный в память образ, поскольку формат объектного файла содержат дополнительные данные о программе, такие, как использованные разделяемые библиотеки, если они есть.[41]

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

3.2. Выделение памяти

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

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

3.2.1. Библиотечные вызовы: malloc(), calloc(), realloc(), free()

Динамическую память выделяют с помощью функций malloc() или calloc(). Эти функции возвращают указатели на выделенную память. Когда у вас есть блок памяти определенного первоначального размера, вы можете изменить его размер с помощью функции realloc(). Динамическая память освобождается функцией free().

Отладка использования динамической памяти сама по себе является важной темой. Инструменты для этой цели мы обсудим в разделе 15.5.2 «Отладчики выделения памяти».

3.2.1.1. Исследование подробностей на языке С

Вот объявления функций из темы справки GNU/Linux malloc(3):

#include <stdlib.h> /* ISO С */


void *calloc(size_t nmemb, size_t size);

 /* Выделить и инициализировать нулями */

void *malloc(size_t size);

 /* Выделить без инициализации */

void free(void *ptr);

 /* Освободить память */

void *realloc(void *ptr, size_t size);

 /* Изменить размер выделенной памяти */

Функции выделения памяти возвращают тип void*. Это бестиповый или общий указатель, все, что с ним можно делать — это привести его к другому типу и назначить типизированному указателю. Примеры впереди.

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

Тип ptrdiff_t используется для вычисления адреса в арифметике указателей, как в случае вычисления указателя в массиве:

#define MAXBUF ...

char *p;

char buf[MAXBUF];

ptrdiff_t where;


p = buf;

while (/* некоторое условие */) {

 ...

 p += something;

 ...

 where = p - buf; /* какой у нас индекс? */

}

Заголовочный файл <stdlib.h> объявляет множество стандартных библиотечных функций С и типов (таких, как size_t), он определяет также константу препроцессора NULL, которая представляет «нуль» или недействительный указатель. (Это нулевое значение, такое, как 0 или '((void*)0)'. Явное использование 0 относится к стилю С++; в С, однако, NULL является предпочтительным, мы находим его гораздо более читабельным для кода С.)

3.2.1.2. Начальное выделение памяти: malloc()

Сначала память выделяется с помощью malloc(). Передаваемое функции значение является общим числом затребованных байтов. Возвращаемое значение является указателем на вновь выделенную область памяти или NULL, если память выделить невозможно. В последнем случае для обозначения ошибки будет установлен errno. (errno является специальной переменной, которую системные вызовы и библиотечные функции устанавливают для указания произошедшей ошибки. Она описывается в разделе 4.3 «Определение ошибок».) Например, предположим, что мы хотим выделить переменное число некоторых структур. Код выглядит примерно так:

struct coord { /* 3D координаты */

 int x, y, z;

} *coordinates;

unsigned int count; /* сколько нам нужно */

size_t amount; /* общий размер памяти */

/* ... как-нибудь определить нужное число... */

amount = count * sizeof(struct coord); /* сколько байт выделить */

coordinates = (struct coord*)malloc(amount); /* выделить память */

if (coordinates == NULL) {

 /* сообщить об ошибке, восстановить или прервать */

}

/* ... использовать координаты... */

Представленные здесь шаги являются стереотипными. Порядок следующий:

1. Объявить указатель соответствующего типа для выделенной памяти.

2. Вычислить размер выделяемой памяти в байтах. Для этого нужно умножить число нужных объектов на размер каждого из них. Последний получается с помощью оператора С sizeof, который для этой цели и существует (наряду с другими). Таким образом, хотя размер определенной структуры среди различных компиляторов и архитектур может различаться, sizeof всегда возвращает верное значение, а исходный код остается правильным и переносимым.

При выделении массивов для строк символов или других данных типа char нет необходимости умножения на sizeof(char), поскольку последнее по определению всегда равно 1. Но в любом случае это не повредит.

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

Обратите внимание, что на C++ присвоение знамения указателя одного типа указателю другого типа требует приведения типов, какой бы ни был контекст. Для управления динамической памятью программы C++ должны использовать new и delete, а не malloc() и free(), чтобы избежать проблем с типами.

4. Проверить возвращенное значение. Никогда не предполагайте, что выделение памяти было успешным. Если выделение памяти завершилось неудачей, malloc() возвращает NULL. Если вы используете значение без проверки, ваша программа может быть немедленно завершена из-за нарушения сегментации (segmentation violation), которое является попыткой использования памяти за пределами своего адресного пространства.

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

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

int cur_x, cur_y, cur_z;

size_t an_index;

an_index = something;

cur_x = coordinates[an_index].x;

cur_y = coordinates[an_index].y;

cur_z = coordinates[an_index].z;

Компилятор создает корректный код для индексирования через указатель при получении доступа к членам структуры coordinates[an_index].

ЗАМЕЧАНИЕ. Блок памяти, возвращенный malloc(), не инициализирован. Он может содержать любой случайный мусор. Необходимо сразу же инициализировать память нужными значениями или хотя бы нулями. В последнем случае используйте функцию memset() (которая обсуждается в разделе 12.2 «Низкоуровневая память, функции memXXX()):

memset(coordinates, '\0', amount);

Другой возможностью является использование calloc(), которая вскоре будет описана.

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

some_type *pointer;

pointer = malloc(count * sizeof(*pointer));

Этот подход гарантирует, что malloc() выделит правильное количество памяти без необходимости смотреть объявление pointer. Если тип pointer впоследствии изменится, оператор sizeof автоматически гарантирует, что выделяемое число байтов остается правильным. (Методика Джеффа опускает приведение типов, которое мы только что обсуждали. Наличие там приведения типов также гарантирует диагностику, если тип pointer изменится, а вызов malloc() не будет обновлен.)

3.2.1.3. Освобождение памяти: free()

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

free(coordinates);

coordinates = NULL; /* не требуется, но хорошая мысль */

После вызова free(coordinates) доступ к памяти, на которую указывает coordinates, запрещен. Она теперь «принадлежит» процедурам выделения, и они могут поступать с ней как сочтут нужным. Они могут изменить содержимое памяти или даже удалить ее из адресного пространства процесса! Таким образом, есть несколько типичных ошибок, которых нужно остерегаться при использовании free():

Доступ к освобожденной памяти

Если она не была освобождена, переменная coordinates продолжает указывать на блок памяти, который больше не принадлежит приложению. Это называется зависшим указателем (dangling pointer). На многих системах вы можете уйти от наказания, продолжая использовать эту память, по крайней мере до следующего выделения или освобождения памяти. На других системах, однако, такой доступ не будет работать. В общем, доступ к освобожденной памяти является плохой мыслью: это непереносимо и ненадежно, и GNU Coding Standards отвергает его. По этой причине неплохо сразу же установить в указателе программы значение NULL. Если затем вы случайно попытаетесь получить доступ к освобожденной памяти, программа немедленно завершится с ошибкой нарушения сегментации (надеемся, до того, как вы успели вашу программу выпустить в свет).

Освобождение одного и того же указателя дважды

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

Передача указателя, полученного не от функций malloc(), calloc() или realloc()

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

free(coordinates + 10);

/* Освободить все кроме первых 10 элементов */

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

Выход за пределы буфера

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

Отказ в освобождении памяти

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

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

Хотя free() может вернуть освобожденную память системе и сократить адресное пространство процесса, это почти никогда не делается. Вместо этого освобожденная память готова для нового выделения при следующем вызове malloc(), calloc() или realloc().

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

Обсуждение ряда полезных инструментов для отладки динамической памяти см в разделе 15.5.2 «Отладчики выделения памяти».

3.2.1.4. Изменение размера: realloc()

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

Вдобавок, можно изменять размер динамически выделенной области памяти. Хотя можно сократить размер блока памяти, обычно его увеличивают. Изменение размера осуществляется с помощью realloc(). Продолжая пример с coordinates, типичный код выглядит следующим образом:

int new_count;

size_t new_amount;

struct coord *newcoords; /* установить, например: */

new_count = count * 2; /* удвоить размер памяти */

new_amount = new_count * sizeof(struct coord);

newcoords =

 (struct coord*)realloc(coordinates, new_amount);

if (newcoords == NULL) {

 /* сообщить об ошибке, восстановить или прервать */

}

coordinates = newcoords;

/* продолжить использование coordinates ... */

Как и в случае с malloc(), шаги стереотипны по природе и сходны по идее.

1. Вычислить новый выделяемый размер в байтах.

2. Вызвать realloc() с оригинальным указателем, полученным от malloc() (или от calloc() или предыдущего вызова realloc()) и с новым размером.

3. Привести тип и присвоить возвращенное realloc() значение. Подробнее обсудим дальше.

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

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

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

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

coordinates = realloc(coordinates, new_amount);

Это плохо по следующей причине. Когда realloc() возвращает NULL, первоначальный указатель все еще действителен; можно безопасно продолжить использовать эту память. Но если вы повторно используете ту же самую переменную и realloc() возвращает NULL, вы теряете указатель на первоначальную память. Эту память больше нельзя использовать. Что еще важнее, эту память невозможно освободить! Это создает утечку памяти, которую нужно избежать.

Для версии realloc() в стандартном С есть некоторые особые случаи: когда аргумент ptr равен NULL, realloc() действует подобно malloc() и выделяет свежий блок памяти. Когда аргумент size равен 0, realloc() действует подобно free() и освобождает память, на которую указывает ptr. Поскольку (а) это может сбивать с толку и (б) более старые системы не реализуют эту возможность, мы рекомендуем использовать malloc(), когда вы имеете в виду malloc(), и free(), когда вы имеете в виду free().

Вот другой довольно тонкий момент[42]. Рассмотрим процедуру, которая содержит статический указатель на динамически выделяемые данные, которые время от времени должны расти. Процедура может содержать также автоматические (т.е. локальные) указатели на эти данные. (Для краткости, мы опустим проверки ошибок. В коде продукта не делайте этого.) Например:

void manage_table(void) {

 static struct table *table;

 struct table *cur, *p;

 int i;

 size_t count;

 ...

 table =

  (struct table*)malloc(count * sizeof(struct table));

 /* заполнить таблицу */

 cur = &table[i]; /* указатель на 1-й элемент */

 ...

 cur->i = j; /* использование указателя */

 ...

 if (/* некоторое условие */) {

  /* нужно увеличить таблицу */

  count += count/2;

  p =

  (struct table*)realloc(table, count * sizeof(struct table));

  table = p;

 }

 cur->i = j; /* ПРОБЛЕМА 1: обновление элемента таблицы */

 other_routine(); /* ПРОБЛЕМА 2: см. текст */

 cur->j = k; /* ПРОБЛЕМА 2: см. текст */

 ...

}

Это выглядит просто; manage_table() размешает данные, использует их, изменяет размер и т.д. Но есть кое-какие проблемы, которые не выходят за рамки страницы (или экрана), когда вы смотрите на этот код.

В строке, помеченной 'ПРОБЛЕМА 1', указатель cur используется для обновления элемента таблицы. Однако, cur был инициализирован начальным значением table. Если некоторое условие верно и realloc() вернула другой блок памяти, cur теперь указывает на первоначальный, освобожденный участок памяти! Каждый раз, когда table меняется, нужно обновить также все указатели на этот участок памяти. Здесь после вызова realloc() и переназначения table недостает строки 'cur = &table[i];'.

Две строки, помеченные 'ПРОБЛЕМА 2', еще более тонкие. В частности, предположим, что other_routine() делает рекурсивный вызов manage_table(). Переменная table снова может быть изменена совершенно незаметно! После возвращения из other_routine() значение cur может снова стать недействительным.

Можно подумать (что мы вначале и сделали), что единственным решением является знать это и добавить после вызова функции переназначение cur с соответствующим комментарием. Однако, Брайан Керниган (Brian Kernighan) любезно нас поправил. Если мы используем индексирование, проблема поддержки указателя даже не возникает:

table =

 (struct table*)malloc(count * sizeof(struct table));

...

/* заполнить таблицу */

...

table[i].i = j; /* Обновить член i-го элемента */

...

if (/* некоторое условие */) {

 /* нужно увеличить таблицу */

 count += count/2;

 p =

  (struct table*)realloc(table, count * sizeof(struct table));

 table = p;

}

table[i].i = j; /* ПРОБЛЕМА 1 устраняется */

other_routine();

/* Рекурсивный вызов, модифицирует таблицу */

table[i].j = k; /* ПРОБЛЕМА 2 также устраняется */

Использование индексирования не решает проблему, если вы используете глобальную копию первоначального указателя на выделенные данные; в этом случае, вам все равно нужно побеспокоиться об обновлении своих глобальных структур после вызова realloc().

ЗАМЕЧАНИЕ. Как и в случае с malloc(), когда вы увеличиваете размер памяти, вновь выделенная после realloc() память не инициализируется нулями. Вы сами при необходимости должны очистить память с помощью memset(), поскольку realloc() лишь выделяет новую память и больше ничего не делает.

3.2.1.5. Выделение с инициализацией нулями: calloc()

Функция calloc() является простой оболочкой вокруг malloc(). Главным ее преимуществом является то, что она обнуляет динамически выделенную память. Она также вычисляет за вас размер памяти, принимая в качестве параметра число элементов и размер каждого элемента:

coordinates = (struct coord*)calloc(count, sizeof(struct coord));

По крайней мере идейно, код calloc() довольно простой. Вот одна из возможных реализаций:

void *calloc(size_t nmemb, size_t size) {

 void *p;

 size_t total;

 total = nmemb * size;   /* Вычислить размер */

 p = malloc(total);      /* Выделить память */

 if (p != NULL)          /* Если это сработало - */

 memset(p, '\0', total); /* Заполнить ее нулями */

 return p; /* Возвращаемое значение NULL или указатель */

}

Многие опытные программисты предпочитают использовать calloc(), поскольку в этом случае никогда не возникает вопросов по поводу вновь выделенной памяти.

Если вы знаете, что вам понадобится инициализированная нулями память, следует также использовать calloc(), поскольку возможно, что память, возвращенная malloc(), уже заполнена нулями. Хотя вы, программист, не можете этого знать, calloc() может это знать и избежать лишнего вызова memset().

3.2.1.6. Подведение итогов из GNU Coding Standards

Чтобы подвести итоги, процитируем, что говорит об использовании процедур выделения памяти GNU Coding Standards:

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

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

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

В этих трех коротких абзацах Ричард Столмен (Richard Stallman) выразил суть важных принципов управления динамической памятью с помощью malloc(). Именно использование динамической памяти и принцип «никаких произвольных ограничений» делают программы GNU такими устойчивыми и более работоспособными по сравнению с их Unix-двойниками.

Мы хотим подчеркнуть, что стандарт С требует, чтобы realloc() не разрушал оригинальный блок памяти, если она возвращает NULL.

3.2.1.7. Использование персональных программ распределения

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

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

Например, GNU awk (gawk) использует эту методику. Выдержка из файла awk.h в дистрибутиве gawk (слегка отредактировано, чтобы уместилось на странице):

#define getnode(n) if (nextfree) n = nextfree, \

 nextfree = nextfree->nextp; else n = more_nodes()

#define freenode(n) ((n)->flags = 0, (n)->exec_count = 0,\

 (n)->nextp = nextfree, nextfree = (n))

Переменная nextfree указывает на связанный список структур NODE. Макрос getnode() убирает из списка первую структуру, если она там есть. В противном случае она вызывает more_nodes(), чтобы выделить новый список свободных структур NODE. Макрос freenode() освобождает структуру NODE, помещая его в начало списка.

ЗАМЕЧАНИЕ. Первоначально при написании своего приложения делайте это простым способом: непосредственно используйте malloc() и free(). Написание собственного распределителя вы должны рассмотреть лишь в том и только в том случае, если профилирование вашей программы покажет, что она значительную часть времени проводит в функциях выделения памяти.

3.2.1.8. Пример: чтение строк произвольной длины

Поскольку это, в конце концов, Программирование на Linux в примерах, настало время для примера из реальной жизни. Следующий код является функцией readline() из GNU Make 3.80 (ftp://ftp.gnu.org/gnu/make/make-3.80.tar.gz). Ее можно найти в файле read.c.

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

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

struct ebuffer {

 char *buffer;      /* Начало текущей строки в буфере. */

 char *bufnext;     /* Начало следующей строки в буфере. */

 char *bufstart;    /* Начало всего буфера. */

 unsigned int size; /* Размер буфера для malloc. */

 FILE *fp;          /* Файл или NULL, если это внутренний буфер. */

 struct floc floc;  /* Информация о файле в fp (если он есть). */

};

Поле size отслеживает размер всего буфера, a fp является указателем типа FILE для файла ввода. Структура floc не представляет интереса при изучении процедуры.

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

1  static long

2  readline(ebuf) /* static long readline(struct ebuffer *ebuf) */

3  struct ebuffer *ebuf;

4  {

5   char *p;

6   char *end;

7   char *start;

8   long nlines = 0;

9

10  /* Использование строковых буферов и буферов потоков достаточно

11     различается, чтобы использовать разные функции. */

12

13  if (!ebuf->fp)

14   return readstring(ebuf);

15

16  /* При чтении из файла для каждой новой строки мы всегда

17     начинаем с начала буфера. */

18

19  p = start = ebuf->bufstart;

20  end = p + ebuf->size;

21  *p = '\0';

Для начала заметим, что GNU Make написан на С K&R для максимальной переносимости. В исходной части объявляются переменные, и если ввод осуществляется из строки (как в случае расширения макроса), код вызывает другую функцию, readstring() (строки 13 и 14). Строка '!ebuf->fp' (строка 13) является более короткой (и менее понятной, по нашему мнению) проверкой на пустой указатель; это то же самое, что и 'ebuf->fp==NULL'.

Строки 19-21 инициализируют указатели и вводят байт NUL, который является символом завершения строки С в конце буфера. Затем функция входит в цикл (строки 23–95), который продолжается до завершения всего ввода.

23 while (fgets(p, end - р, ebuf->fp) != 0)

24 {

25  char *p2;

26  unsigned long len;

27  int backslash;

28

29  len = strlen(p);

30  if (len == 0)

31  {

32   /* Это случается лишь тогда, когда первый символ строки '\0'.

33      Это довольно безнадежный случай, но (верите или нет) ляп Афины

34      бьет снова! (xmkmf помещает NUL в свои makefile.)

35      Здесь на самом деле нечего делать; мы создаем новую строку, чтобы

36      следующая строка не была частью данной строки. */

37   error (&ebuf->floc,

38    _("warning: NUL character seen; rest of line ignored"));

39   p[0] = '\n';

40   len = l;

41  }

Функция fgets() (строка 23) принимает указатель на буфер, количество байтов для прочтения и переменную FILE* для файла, из которого осуществляется чтение. Она читает на один байт меньше указанного, чтобы можно было завершить буфер символом '\0'. Эта функция подходит, поскольку она позволяет избежать переполнения буфера. Она прекращает чтение, когда встречается с символами конца строки или конца файла; если это символ новой строки, он помещается в буфер. Функция возвращает NULL при неудаче или значение указателя первого аргумента при успешном завершении.

В этом случае аргументами являются указатель на свободную область буфера, размер оставшейся части буфера и указатель FILE для чтения.

Комментарии в строках 32–36 очевидны; если встречается нулевой байт, программа выводит сообщение об ошибке и представляет вывод как пустую строку. После компенсирования нулевого байта (строки 30–41) код продолжает работу.

43 /* Обойти только что прочитанный текст. */

44 p += len;

45

46 /* Если последний символ - не конец строки, она не поместилась

47    целиком в буфер. Увеличить буфер и попытаться снова. */

48 if (p[-1] != '\n')

49  goto more_buffer;

50

51 /* Мы получили новую строку, увеличить число строк. */

52 ++nlines;

Строки 43–52 увеличивают указатель на участок буфера за только что прочитанными данными. Затем код проверяет, является ли последний прочитанный символ символом конца строки. Конструкция p[-1] (строка 48) проверяет символ перед p, также как p[0] является текущим символом, а p[1] — следующим. Сначала это кажется странным, но если вы переведете это на язык математики указателей, *(p-1), это приобретет больший смысл, а индексированная форма, возможно, проще для чтения.

Если последний символ не был символом конца строки, это означает, что нам не хватило места, и код выходит (с помощью goto) для увеличения размера буфера (строка 49). В противном случае увеличивается число строк.

54 #if !defined(WINDOWS32) && !defined(__MSDOS__)

55 /* Проверить, что строка завершилась CRLF; если так,

56    игнорировать CR. */

57 if ((p - start) > 1 && p[-2] == '\r')

58 {

59  --p;

60  p[-1] = '\n';

61 }

62 #endif

Строки 54–62 обрабатывают вводимые строки, следующие соглашению Microsoft по завершению строк комбинацией символов возврата каретки и перевода строки (CR-LF), а не просто символом перевода строки (новой строки), который является соглашением Linux/Unix. Обратите внимание, что #ifdef исключает этот код на платформе Microsoft, очевидно, библиотека <stdio.h> на этих системах автоматически осуществляет это преобразование. Это верно также для других не-Unix систем, поддерживающих стандартный С.

64  backslash = 0;

65  for (p2 = p - 2; p2 >= start; --p2)

66  {

67   if (*p2 != '\\')

68   break;

69   backslash = !backslash;

70  }

71

72  if (!backslash)

73  {

74   p[-1] = '\0';

75   break;

76  }

77

78  /* Это была комбинация обратный слеш/новая строка. Если есть

79     место, прочесть еще одну строку. */

80  if (end - p >= 80)

81   continue;

82

83  /* В конце буфера нужно больше места, поэтому выделить еще.

84     Позаботиться о сохранении текущего смещения в p. */

85 more_buffer:

86  {

87   unsigned long off = p - start;

88   ebuf->size *= 2;

89   start = ebuf->buffer=ebuf->bufstart=(char*)xrealloc(start,

90    ebuf->size);

91   p = start + off;

92   end = start + ebuf->size;

93   *p = '\0';

94  }

95 }

До сих пор мы имели дело с механизмом получения в буфер по крайней мере одной полной строки. Следующий участок обрабатывает случай строки с продолжением. Хотя он должен гарантировать, что конечный символ обратного слеша не является частью нескольких обратных слешей в конце строки. Код проверяет, является ли общее число таких символов четным или нечетным путем простого переключения переменной backslash из 0 в 1 и обратно. (Строки 64–70.)

Если число четное, условие '!backshlash' (строка 72) будет истинным. В этом случае конечный символ конца строки замещается байтом NUL, и код выходит из цикла.

С другой стороны, если число нечетно, строка содержит четное число пар обратных слешей (представляющих символы \\, как в С), и конечную комбинацию символов обратного слеша и конца строки.[43] В этом случае, если в буфере остались по крайней мере 80 свободных байтов, программа продолжает чтение в цикле следующей строки (строки 78–81). (Использование магического числа 80 не очень здорово; было бы лучше определить и использовать макроподстановку.)

По достижении строки 83 программе нужно больше места в буфере. Именно здесь вступает в игру динамическое управление памятью. Обратите внимание на комментарий относительно сохранения значения p (строки 83-84); мы обсуждали это ранее в терминах повторной инициализации указателей для динамической памяти. Значение end также устанавливается повторно. Строка 89 изменяет размер памяти.

Обратите внимание, что здесь вызывается функция xrealloc(). Многие программы GNU используют вместо malloc() и realloc() функции-оболочки, которые автоматически выводят сообщение об ошибке и завершают программу, когда стандартные процедуры возвращают NULL. Такая функция-оболочка может выглядеть таким образом:

extern const char *myname; /* установлено в main() */


void *xrealloc(void *ptr, size_t amount) {

 void *p = realloc(ptr, amount);

 if (p == NULL) {

  fprintf(stderr, "%s: out of memory!\n", myname);

  exit(1);

 }

 return p;

}

Таким образом, если функция xrealloc() возвращается, она гарантированно возвращает действительный указатель. (Эта стратегия соответствует принципу «проверки каждого вызова на ошибки», избегая в то же время беспорядка в коде, который происходит при таких проверках с непосредственным использованием стандартных процедур.) Вдобавок, это позволяет эффективно использовать конструкцию 'ptr = xrealloc(ptr, new_size)', против которой мы предостерегали ранее.

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

97   if (ferror(ebuf->fp))

98    pfatal_with_name(ebuf->floc.filenm);

99

100  /* Если обнаружено несколько строк, возвратить их число.

101     Если не несколько, но _что-то_ нашли, значит, прочитана

102     последняя строка файла без завершающего символа конца

103     строки; вернуть 1. Если ничего не прочитано, это EOF;

104     возвратить -1. */

105  return nlines ? nlines : p == ebuf->bufstart ? -1 : 1;

106 }

В заключение, функция readline() проверяет ошибки ввода/вывода, а затем возвращает описательное значение. Функция pfatal_with_name() (строка 98) не возвращается.[44]

3.2.1.9. Только GLIBC: чтение целых строк: getline() и getdelim()

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

#define _GNU_SOURCE 1 /* GLIBC */

#include <stdio.h>

#include <sys/types.h> /* для ssize_t */


ssize_t getline(char **lineptr, size_t *n, FILE *stream);

ssize_t getdelim(char **lineptr, size_t *n, int delim, FILE *stream);

Определение константы _GNU_SOURCE вводит объявления функций getline() и getdelim(). В противном случае они неявно объявлены как возвращающие int. Для объявления возвращаемого типа ssize_t нужен файл <sys/types.h>. (ssize_t является «знаковым size_t». Он предназначен для такого же использования, что и size_t, но в местах, где может понадобиться использование также и отрицательных значений.)

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

char **lineptr

Указатель на char* указатель для адреса динамически выделенного буфера. Чтобы getline() сделала всю работу, он должен быть инициализирован NULL. В противном случае, он должен указывать на область памяти, выделенную с помощью malloc().

size_t *n

Указатель на размер буфера. Если вы выделяете свой собственный буфер, *n должно содержать размер буфера. Обе функции обновляют *n новым значением размера буфера, если они его изменяют.

FILE* stream

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

По достижении конца файла или при ошибке функция возвращает -1. Строки содержат завершающий символ конца строки или разделитель (если он есть), а также завершающий нулевой байт. Использование getline() просто, как показано в ch03-getline.с:

/* ch03-getline.c --- демонстрация getline(). */

#define _GNU_SOURCE 1

#include <stdio.h>

#include <sys/types.h>


/* main - прочесть строку и отобразить ее, пока не достигнут EOF */

int main(void) {

 char *line = NULL;

 size_t size = 0;

 ssize_t ret;

 while ((ret = getline(&line, &size, stdin)) != -1)

  printf("(%lu) %s", size, line);

 return 0;

}

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

$ ch03-getline /* Запустить программу */

this is a line

(120) this is a line

And another line.

(120) And another line.

A llllllllllllllllloooooooooooooooooooooooooooooooonnnnnnnnnnnnnnnngnnnggggggggggg llliiiiiiiiiiiiiiiiiiinnnnnnnnnnnnnnnnnnnneeeeeeeeee

(240) A llllllllllllllllloooooooooooooooooooooooooooooooonnnnnnnnnnnnnnnngnnnggggggggggg llliiiiiiiiiiiiiiiiiiinnnnnnnnnnnnnnnnnnnneeeeeeeeee

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

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

#include <string.h>


/* 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 <string.h> /* XSI */


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

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

3.2.3. Системные вызовы: brk() и sbrk()

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

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

#include <unistd.h> /* Обычный */

#include <malloc.h> /* Необходим для систем 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 <alloca.h> /* Обычный */


void *alloca(size_t size);

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

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

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

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

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

• Цитируя справку[45] (добавлено выделение): «Функция 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 <stdio.h>

7  #include <malloc.h> /* для определения ptrdiff_t в GLIBC */

8  #include <unistd.h>

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

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

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

3.3. Резюме

• У каждой программы Linux и (Unix) есть различные области памяти. Они хранятся в разных частях файла исполняемой программы на диске. Некоторые из секций загружаются при запуске программы в одну и ту же область памяти. Все запушенные экземпляры одной и той же программы разделяют исполняемый код (сегмент текста). Программа size показывает размеры различных областей переместимых объектных файлов и полностью скомпонованных исполняемых файлов.

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

• На уровне языка С память выделяется с помощью одной из функций malloc(), calloc() или realloc(). Память освобождается с помощью free(). (Хотя с помощью realloc() можно делать все, использование ее таким образом не рекомендуется.) Освобожденная память обычно не удаляется из адресного пространства; вместо этого она используется повторно при последующих выделениях.

• Необходимо предпринять чрезвычайные меры осторожности в следующих случаях

 • освобождать лишь память, выделенную с помощью соответствующих процедур,

 • освобождать память один и только один раз,

 • освобождать неиспользуемую память и

 • не допускать «утечки» динамически выделяемой памяти.

• POSIX предоставляет для удобства функцию strdup(), a GLIBC предоставляет функции getline() и getdelim() для чтения строк произвольной длины. Функции интерфейса низкоуровневых системных вызовов brk() и sbrk() предоставляют непосредственный, но примитивный доступ к выделению и освобождению памяти. Если вы не создаете свой собственный распределитель памяти, следует избегать их. Существует функция alloca() для выделения памяти в стеке, но ее использование не рекомендуется. Подобно умению распознавать ядовитый плющ, про нее нужно знать лишь для того, чтобы избегать ее.

Упражнения

1. Начав со структуры —

struct line {

 size_t buflen;

 char *buf;

 FILE* fp;

};

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

2. Сохраняет ли ваша функция завершающий символ конца строки? Объясните, почему.

3. Как ваша функция обрабатывает строки, оканчивающиеся CR-LF?

4. Как вы инициализируете структуру? В отдельной процедуре? С помощью документированных условий для определенных значений в структуре?

5. Как вы обозначаете конец файла? Как вы указываете, что возникла ошибка ввода/вывода? Должна ли ваша функция сообщать об ошибках? Объясните, почему.

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

7. Перепишите вашу функцию с использованием fgets() и протестируйте ее. Является ли новый код более сложным или менее сложным? Какова его производительность по сравнению с версией getc()?

8. Изучите страницу справки V7 для end(3) (/usr/man/man3/end.3 в дистрибутиве V7). Пролила ли она свет на то, как может работать 'sbrk(0)'?

9. Усовершенствуйте ch03-memaddr.c так, чтобы она печатала расположение аргументов и переменных окружения. В какой области адресного пространства они находятся?

Глава 4 Файлы и файловый ввод/вывод

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

4.1. Введение в модель ввода/вывода Linux/Unix

Модель API Linux/Unix для ввода/вывода проста. Ее можно суммировать четырьмя словами. открыть, прочитать, записать, закрыть. Фактически, это имена системных вызовов: open(), read(), write(), close(). Вот их объявления:

#include <sys/types.h> /* POSIX */

#include <sys/stat.h> /* для mode_t */

#include <fcntl.h>    /* для flags для open() */

#include <unistd.h>   /* для ssize_t */


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

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

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

int close(int fd);

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

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

4.2. Представление базовой структуры программы

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

1  /*

2   * ch04-cat.c --- Демонстрация open(), read(), write(), close(),

3   * errno и strerror().

4   */

5

6  #include <stdio.h> /* для fprintf(), stderr, BUFSIZ */

7  #include <errno.h> /* объявление errno */

8  #include <fcntl.h> /* для flags для open() */

9  #include <string.h> /* объявление strerror() */

10 #include <unistd.h> /* для ssize_t */

11 #include <sys/types.h>

12 #include <sys/stat.h> /* для mode_t */

13

14 char *myname;

15 int process(char *file);

16

17 /* main --- перечислить аргументы файла */

18

19 int

20 main(int argc, char **argv)

21 {

22  int i;

23  int errs = 0;

24

25  myname = argv[0];

26

27  if (argc == 1)

28   errs = process("-");

29  else

30   for (i = 1; i < argc; i++)

31  errs += process(argv[i]);

32

33  return (errs != 0);

34 }

…продолжение далее в главе.

Переменная myname (строка 14) используется далее для сообщений об ошибках; main() первым делом устанавливает в ней имя программы (argv[0]). Затем main() в цикле перечисляет аргументы. Для каждого аргумента она вызывает функцию process().

Когда в качестве имени файла дано - (простая черточка, или знак минус), cat Unix вместо попытки открыть файл с именем читает стандартный ввод. Вдобавок, cat читает стандартный ввод, когда нет аргументов. ch04-cat реализует оба этих поведения. Условие 'argc == 1' (строка 27) истинно, когда нет аргументов имени файла; в этом случае main() передает «-» функции process(). В противном случае, main() перечисляет аргументы, рассматривая их как файлы, которые необходимо обработать. Если один из них окажется «-», программа обрабатывает стандартный ввод.

Если process() возвращает ненулевое значение, это означает, что случилась какая- то ошибка. Ошибки подсчитываются в переменной errs (строки 28 и 31). Когда main() завершается, она возвращает 0, если не было ошибок, и 1, если были (строка 33). Это довольно стандартное соглашение, значение которого более подробно обсуждается в разделе 9.1.5.1 «Определение статуса завершения процесса».

Структура, представленная в main(), довольно общая: process() может делать с файлом все, что мы захотим. Например (игнорируя особый случай «-»), process() также легко могла бы удалять файлы вместо их объединения!

Прежде чем рассмотреть функцию process(), нам нужно описать, как представлены ошибки системных вызовов и как осуществляется ввод/вывод. Сама функция process() представлена в разделе 4.4.3 «Чтение и запись».

4.3. Определение ошибок

«Если неприятность может произойти, она случается»

- Закон Мерфи -

«Будь готов»

- Бойскауты -

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

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

int result;

result = some_system_call(param1, param2);

if (result < 0) {

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

} else

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

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

#include <errno.h> /* 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

Имя Значение
E2BIG Слишком длинный список аргументов
EACCESS Доступ запрещен
EADDRINUSE Адрес используется
EADDRNOTAVAIL Адрес недоступен
EAFNOSUPPORT Семейство адресов не поддерживается
EAGAIN Ресурс недоступен, попытайтесь снова (может быть то же самое значение, что EWOULDBLOCK).
EALREADY Соединение уже устанавливается
EBADF Ошибочный дескриптор файла.
EBADMSG Ошибочное сообщение.
EBUSY Устройство или ресурс заняты
ECANCELED Отмена операции.
ECHILD Нет порожденного процесса.
ECONNABORTED Соединение прервано
ECONNFRFUSED Соединение отклонено
ECONNRESET Восстановлено исходное состояние соединения.
EDEADLK Возможен тупик (deadlock) в запросе ресурса.
EDESTADDRREQ Требуется адрес назначения
EDOM Математический аргумент выходит за область определения функции
EDQUOT Зарезервировано.
EEXIST Файл существует.
EFAULT Ошибочный адрес.
EFBIG Файл слишком большой.
EHOSTUNREACH Хост недоступен.
EIDRM Идентификатор удален
EILSEQ Ошибочная последовательность байтов.
EINPROGRESS Операция исполняется.
EINTR Прерванная функция.
EINVAL Недействительный аргумент.
EIO Ошибка ввода/вывода.
EISCONN Сокет (уже) соединен.
EISDIR Это каталог.
ELOOP Слишком много уровней символических ссылок.
EMFILE Слишком много открытых файлов.
EMLINK Слишком много ссылок.
EMSGSIZE Сообщение слишком длинное.
EMULTIHOP Зарезервировано.
ENAMETOOLONG Имя файла слишком длинное
ENETDOWN Сеть не работает
ENETRESET Соединение прервано сетью
ENETUNREACH Сеть недоступна.
ENFILE В системе открыто слишком много файлов.
ENOBUFS Буферное пространство недоступно.
ENODEV Устройство отсутствует
ENOENT Файл или каталог отсутствуют
ENOEXEC Ошибочный формат исполняемого файла.
ENOLCK Блокировка недоступна.
ENOLINK Зарезервировано.
ENOMEM Недостаточно памяти.
ENOMSG Сообщение нужного типа отсутствует
ENOPROTOOPT Протокол недоступен.
ENOSPC Недостаточно памяти в устройстве.
ENOSYS Функция не поддерживается.
ENOTCONN Сокет не соединен.
ENOTDIR Это не каталог
ENOTEMPTY Каталог не пустой.
ENOTSOCK Это не сокет
ENOTSUP Не поддерживается
ENOTTY Неподходящая операция управления вводом/выводом
ENXIO Нет такого устройства или адреса.
EOPNOTSUPP Операция сокета не поддерживается
EOVERFLOW Слишком большое значение для типа данных
EPERM Операция не разрешена
EPIPE Канал (pipe) разрушен
EPROTO Ошибка протокола.
EPROTONOSUPPORT Протокол не поддерживается
EPROTOTYPE Ошибочный тип протокола для сокета
ERANGE Результат слишком большой
EROFS Файловая система только для чтения
ESPIPE Недействительный поиск
ESRCH Нет такого процесса
ESTALE Зарезервировано
ETIMEDOUT Тайм-аут соединения истек
ETXTBSY Текстовый файл занят
EWOULDBLOCK Блокирующая операция (может быть то же значение, что и для EAGAIN)
EXDEV Ссылка через устройство (cross-device link)

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

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

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

#include <stdio.h> /* ISO С */


void perror(const char *s);

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

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

 perror("system call failed");

 return 1;

}

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

#include <string.h> /* 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

Идентификатор Версия С Значение
__DATE__ C89 Дата компиляции в виде «Mmm nn yyyy»
__FILE_ Оригинальная Имя исходного файла в виде «program.c»
__LINE__ Оригинальная Номер строки исходного файла в виде 42
__TIME__ C89 Время компиляции в виде «hh:mm:ss»
__func__ C99 Имя текущей функции, как если бы было объявлено const char __func__[] = "name"

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

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

4.4. Ввод и вывод

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

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

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

$ ulimit -n

1024

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

#include <unistd.h> /* Обычный */


int getdtablesize(void);

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

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

#include <stdio.h> /* для fprintf(), stderr, BUFSIZ */

#include <unistd.h> /* для 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. Открытие и закрытие файлов

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

#include <sys/types.h> /* POSIX */

#include <sys/stat.h>

#include <fcntl.h>

#include <unistd.h>


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

Три аргумента следующие:

const char *pathname

Строка С, представляющая имя открываемого файла.

int flags

Поразрядное ИЛИ с одной или более констант, определенных в <fcntl.h>. Вскоре мы их рассмотрим.

mode_t mode

Режимы доступа для создаваемого файла. Это обсуждается далее в главе, см. раздел 4.6 «Создание файлов». При открытии существующего файла опустите этот параметр[46].

Возвращаемое open() значение является либо новым дескриптором файла, либо -1, означающим ошибку, в этом случае будет установлена errno. Для простого ввода/вывода аргумент flags должен быть одним из значений из табл. 4.3.


Таблица 4.3. Значения flags для open()

Именованная константа Значение Комментарий
O_RDONLY 0 Открыть файл только для чтения, запись невозможны
O_WRONLY 1 Открыть файл только для записи, чтение невозможно
O_RDWR 2 Открыть файл для чтения и записи

Вскоре мы увидим пример кода. Дополнительные значения flags описаны в разделе 4.6 «Создание файлов». Большой объем ранее написанного кода Unix не использовал эти символические значения. Вместо этого использовались числовые значения. Сегодня это рассматривается как плохая практика, но мы представляем эти значения, чтобы вы их распознали, если встретитесь с ними

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

#include <unistd.h> /* POSIX */


int close(int fd);

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

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

(void)close(fd); /* отказ от возвращаемого значения */

Легкомысленность этого совета в том, что слишком большое количество приведений к void имеют тенденцию загромождать код. Например, несмотря на принцип «всегда проверять возвращаемое значение», чрезвычайно редко можно увидеть код, проверяющий возвращаемое значение printf() или приводящий его к void. Как и со многими аспектами программирования на С, здесь также требуются опыт и рассудительность.

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

Система закрывает все открытые файлы, когда процесс завершается, но — за исключением 0, 1 и 2 — плохая манера полагаться на это.

Когда open() возвращает новый дескриптор файла, она всегда возвращает наименьшее неиспользуемое целое значение. Всегда. Поэтому, если открыты дескрипторы файлов 0–6 и программа закрывает дескриптор файла 5, следующий вызов open() вернет 5, а не 7. Это поведение важно; далее в книге мы увидим, как оно используется для аккуратной реализации многих важных особенностей Unix, таких, как перенаправление ввода/вывода и конвейеризация (piping)

4.4.2.1. Отображение переменных FILE* на дескрипторы файлов

Стандартные библиотечные функции ввода/вывода и переменные FILE* из <stdio.h>, такие, как stdin, stdout и stderr, построены поверх основанных на дескрипторах файлов системных вызовах.

Иногда полезно получить непосредственный доступ к дескриптору файла, связанному с указателем файла <stdio.h>, если вам нужно сделать что-либо, не определенное стандартом С ISO. Функция fileno() возвращает лежащий в основе дескриптор файла:

#include <stdio.h> /* POSIX */


int fileno(FILE *stream);

Пример мы увидим позже, в разделе 4.4.4. «Пример: Unix cat».

4.4.2.2. Закрытие всех открытых файлов

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

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

int i;

/* оставить лишь 0, 1, и 2 */

for (i = 3; i < getdtablesize(); i++)

 (void)close(i);

Предположим, что результат getdtablesize() равен 1024. Этот код работает, но он делает (1024-3)*2 = 2042 системных вызова. 1020 из них не нужны, поскольку возвращаемое значение getdtablesize() не изменяется. Вот лучший вариант этого кода:

int i, fds;

for (i = 3, fds = getdtablesize(); i < fds; i++)

 (void)close(i);

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

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

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

#include <sys/types.h> /* POSIX */

#include <sys/stat.h>

#include <fcntl.h>

#include <unistd.h>


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; эта константа определена В <stdio.h> как «оптимальный» размер блока для ввода/вывода. Хотя значение 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[47]. Она начинается с проверки опций, cat V7 принимает единственную опцию, -u, для осуществления небуферированного вывода.

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

1  /*

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

3   */

4

5  #include <stdio.h>

6  #include <sys/types.h>

7  #include <sys/stat.h>

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.

4.5. Произвольный доступ: перемещения внутри файла

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

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

#include <sys/types.h> /* для off_t; POSIX */

#include <unistd.h> /* объявления lseek() и значений whence */


off_t lseek(int fd, off_t offset, int whence);

Тип off_t (тип смещения) является знаковым целым, представляющим позиции байтов (смещений от начала) внутри файла. На 32-разрядных системах тип представлен обычно как long. Однако, многие современные системы допускают очень большие файлы, в этом случае off_t может быть более необычным типом, таким, как C99 int64_t или какой-нибудь другой расширенный тип. lseek() принимает три следующих аргумента.

int fd

Дескриптор открытого файла.

off_t offset

Позиция, в которую нужно переместиться. Интерпретация этого значения зависит от параметра whence. offset может быть положительным или отрицательным; отрицательные значения перемещают к началу файла; положительные значения перемещают к концу файла.

int whence

Описывает положение в файле, относительно которого отсчитывается offset. См. табл. 4.4.


Таблица 4.4. Значения whence для lseek()

Именованная константа Значение Комментарий
SEEK_SET 0 offset абсолютно, т.е. относительно начала файла
SEEK_CUR 1 offset относительно текущей позиции в файле
SEEK_END 2 offset относительно конца файла.

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

Смысл значений и их действие на положение в файле показаны на рис. 4.1. При условии, что файл содержит 3000 байтов и что перед каждым вызовом lseek() текущим является смещение 2000 байтов, новое положение после каждого вызова будет следующим.

Рис. 4.1. Смещения для lseek()

Отрицательные смещения относительно начала файла бессмысленны; они вызывают ошибку «недействительный параметр».

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

off_t curpos;

...

curpos = lseek(fd, (off_t)0, SEEK_CUR);

Буква l в lseek() означает long. lseek() был введен в V7 Unix, когда размеры файлов были увеличены; в V6 был простой системный вызов seek(). В результате большое количество старой документации (и кода) рассматривает параметр offset как имеющий тип long, и вместо приведения к типу off_t довольно часто можно видеть суффикс L в константных значениях смешений:

curpos = lseek(fd, 0L, SEEK_CUR);

На системах с компилятором стандартного С, где lseek() объявлена с прототипом, такой старый код продолжает работать, поскольку компилятор автоматически преобразует 0L из long в off_t, если это различные типы.

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

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

1  /* ch04-holes.c --- Демонстрация lseek() и дыр в файлах. */

2

3  #include <stdio.h> /* для fprintf(), stderr, BUFSIZ */

4  #include <errno.h> /* объявление errno */

5  #include <fcntl.h> /* для flags для open() */

6  #include <string.h> /* объявление strerror() */

7  #include <unistd.h> /* для ssize_t */

8  #include <sys/types.h> /* для off_t, etc. */

9  #include <sys/stat.h>  /* для mode_t */

10

11 struct person {

12  char name[10]; /* имя */

13  char id[10]; /* идентификатор */

14  off_t pos; /* положение в файле для демонстрации */

15 } people[] = {

16  { "arnold", "123456789", 0 },

17  { "miriam", "987654321", 10240 },

18  { "joe", "192837465", 81920 },

19 };

20

21 int

22 main(int argc, char **argv)

23 {

24  int fd;

25  int i, j;

26

27  if (argc < 2) {

28   fprintf(stderr, "usage: %s file\n", argv[0]);

29   return 1;

30  }

31

32  fd = open(argv[1], O_RDWR | O_CREAT | O_TRUNC, 0666);

33  if (fd < 0) {

34   fprintf(stderr, "%s: %s: cannot open for read/write: %s\n",

35    argv[0], argv[1], strerror(errno));

36   return 1;

37  }

38

39  j = sizeof(people) / sizeof(people[0]); /* число элементов */

Строки 27–30 гарантируют, что программа была вызвана правильно. Строки 32–37 открывают именованный файл и проверяют успешность открытия.

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

Работа осуществляется в цикле (строки 41–55), который отыскивает смещение байтов, приведенное в каждой структуре (строка 42), а затем записывает всю структуру (строка 49):

41  for (i = 0; i < j; i++) {

42   if (lseek(fd, people[i].pos, SEEK_SET) < 0) {

43    fprintf(stderr, "%s: %s: seek error: %s\n",

44     argv[0], argv[1], strerror(errno));

45    (void)close(fd);

46    return 1;

47   }

48

49   if (write(fd, &people[i], sizeof(people[i])) != sizeof(people[i])) {

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

51     argv[0], argv[1], strerror(errno));

52    (void)close(fd);

53    return 1;

54   }

55  }

56

57  /* здесь все нормально */

58  (void)close(fd);

59  return 0;

60 }

Вот результаты запуска программы:

$ ch04-holes peoplelist /* Запустить программу */

$ ls -ls peoplelist /* Показать использованные размеры и блоки */

16 -rw-r--r-- 1 arnold devel 81944 Mar 23 17:43 peoplelist

$ echo 81944 / 4096 | bc -l /* Показать блоки, если нет дыр */

20.00585937500000000000

Случайно мы знаем, что каждый дисковый блок файла использует 4096 байтов. (Откуда мы это знаем, обсуждается в разделе 5 4.2 «Получение информации о файле». Пока примите это как данное.) Финальная команда bc указывает, что файлу размером 81944 байтов нужен 21 дисковый блок. Однако, опция -s команды ls, которая сообщает нам, сколько блоков использует файл на самом деле, показывает, что файл использует лишь 16 блоков![48] Отсутствующие блоки в файле являются дырами. Это показано на рис. 4.2.

Рис. 4.2. Дыры в файле

ЗАМЕЧАНИЕch04-holes.c не осуществляет непосредственный двоичный ввод/вывод. Это хорошо демонстрирует красоту ввода/вывода с произвольным доступом: вы можете рассматривать дисковый файл, как если бы он был очень большим массивом двоичных структур данных.

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

4.6. Создание файлов

Как было описано ранее, 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 для одной или более символических имен из <sys/stat.h>, описанных в табл. 4.5.


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

Символическое имя Значение Комментарий
S_IRWXU 00700 Разрешение на чтение, запись и исполнение для владельца
S_IRUSR 00400 Разрешение на чтение для владельца
S_IREAD Аналогично S_IRUSR
S_IWUSR 00200 Разрешение на запись для владельца
S_IWRITE Аналогично S_IWUSR
S_IXUSR 00100 Разрешение на исполнение для владельца.
S_IEXEC Аналогично S_IXUSR
S_IRWXG 00070 Разрешение на чтение, запись и исполнение для группы
S_IRGRP 00040 Разрешение на чтение для группы
S_IWGRP 00020 Разрешение на запись для группы.
S_IXGRP 00010 Разрешение на исполнение для группы
S_IRWXO 00007 Разрешение на чтение, запись и исполнение для остальных.
S_IROTH 00004 Разрешение на чтение для остальных.
S_IWOTH 00002 Разрешение на запись для остальных
S_IXOTH 00001 Разрешение на исполнение для остальных

Следующий фрагмент показывает, как создать переменные, представляющие разрешения -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 для режимов доступа к файлам

Символическое имя Значение Смысл
S_ISUID 04000 Установить ID пользователя
S_ISGID 02000 Установить ID группы
S_ISVTX 01000 Сохранить текст

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

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

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

#include <sys/types.h> /* POSIX */

#include <sys/stat.h> 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()[49] создает новые файлы. Он объявлен следующим образом:

#include <sys/types.h> /* POSIX */

#include <sys/stat.h>

#include <fcntl.h>


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_CREAT Создает новый файл, если он не существует.
O_EXCL При использовании вместе с O_CREAT возвращает ошибку, если файл уже существует
O_TRUNC Урезает файл (устанавливает его длину в 0), если он существует.

Если даны 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_APPEND Принудительно осуществляет все записи в конец файла
O_CREAT Создает новый файл, если он не существует.
O_EXCL При использовании вместе с O_CREAT возвращает ошибку, если файл уже существует
O_TRUNC Урезает файл (устанавливает его длину в 0), если он существует.

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

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

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

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

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

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

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

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

4.7. Форсирование записи данных на диск

Ранее мы описали флаги O_DSYNC, O_RSYNC и O_SYNC для open(). Мы отметили, что использование этих флагов может замедлить программу, поскольку write() не возвращается до тех пор, пока все данные не будут записаны на физический носитель.

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

#include <unistd.h>


int fsync(int fd); /* POSIX FSC */

int fdatasync(int fd); /* POSIX SIO */

Системный вызов fdatasync() подобен O_DSYNC: он форсирует запись данных на конечное физическое устройство. Системный вызов fsync() подобен O_SYNC, форсируя запись на физическое устройство не только данных файла, но и вспомогательных данных. Вызов fsync() более переносим; он существовал в мире Unix в течение более продолжительного времени, и вероятность его наличия среди широкого ряда систем больше.

Можно использовать эти вызовы с указателями файлов <stdio.h>, вызвав сначала fflush(), а затем fileno() для получения дескриптора нижележащего файла. Вот функция fpsync(), которая может использоваться для заключения обеих операций в один вызов. Она возвращает в случае успеха 0:

/* fpsync --- синхронизация переменной stdio FILE* */

int fpsync(FILE *fp) {

 if (fp == NULL || fflush(fp) == EOF || fsync(fileno(fp)) < 0)

  return -1;

 return 0;

}

Технически оба этих вызова являются расширениями базового стандарта POSIX: fsync() в расширении «Синхронизация файлов» (FSC), a fdatasync() в расширении «Синхронизированный ввод и вывод». Тем не менее, можно без проблем использовать их в системе GNU/Linux

4.8. Установка длины файла

Два системных вызова позволяют настраивать размер файла:

#include <unistd.h>

#include <sys/types.h>


int truncate(const char *path, off_t length); /* XSI */

int ftruncate(int fd, off_t length); /* POSIX */

Как должно быть очевидно из параметров, truncate() принимает аргумент имени файла, тогда как ftruncate() работает с дескриптором открытого файла. (Обычным является соглашение по именованию пар системных вызовов xxx() и fxxxx(), работающих с именами файлов и дескрипторами файлов. Мы увидим несколько примеров в данной и последующих главах.) В обоих случаях аргумент length является новым размером файла.

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

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

Эти вызовы сильно отличаются от 'open(file, ... | O_TRUNC, mode)', который полностью урезает файл, отбрасывая все его данные. Эти же вызовы просто устанавливают абсолютную длину файла в данное значение.

Эти функции довольно специализированы; они используются лишь четыре раза во всем коде GNU Coreutils. Мы представляем пример использования ftruncate() в разделе 5.5.3 «Изменение отметок времени: utime()».

4.9. Резюме

• Когда системный вызов завершается неудачей, он обычно возвращает -1, а в глобальной переменной errno устанавливается предопределенное значение, указывающее на проблему. Для сообщений об ошибках могут использоваться функции perror() и strerror().

• Доступ к файлам осуществляется через небольшие целые, которые называются дескрипторами. Дескрипторы файлов для стандартного ввода, стандартного вывода и стандартной ошибки наследуются от родительского процесса программы. Другие получаются через open() или creat(). Для их закрытия используется close(), a getdtablesize() возвращает разрешенное максимальное число открытых файлов. Значение umask (устанавливаемое с помощью umask()) влияет на права доступа, получаемые новыми файлами при создании с помощью creat() или с флагом O_CREAT для open().

• Системные вызовы read() и write() соответственно читают и записывают данные. Их интерфейс прост. В частности, они не интерпретируют данные, файлы представлены линейными потоками байтов. Системный вызов lseek() осуществляет ввод/выводе произвольным доступом: возможность перемещаться внутри файла.

• Для синхронного ввода/вывода предусмотрены дополнительные флаги для open(), при этом данные записываются на физический носитель данных до возвращения write() или read(). Можно также форсировать запись данных на диск на управляемой основе с помощью fsync() или fdatasync().

• Системные вызовы truncate() и ftruncate() устанавливают абсолютную длину файла. (На более старых системах они могут использоваться лишь для сокращения длины файла; на современных системах они могут также увеличивать файл.)

Упражнения

1. Используя лишь open(), read(), write() и close(), напишите простую программу copy, которая копирует файл, имя которого дается в первом аргументе, в файл с именем во втором аргументе.

2. Усовершенствуйте программу copy так, чтобы она принимала "-" в значении «стандартный ввод» при использовании в качестве первого аргумента и в значении «стандартный вывод» в качестве второго аргумента. Правильно ли работает 'copy - -'?

3. Просмотрите страничку справки для proc(5) на системе GNU/Linux. В частности, посмотрите подраздел fd. Выполните 'ls -l /dev/fd' и непосредственно проверьте файлы в /proc/self/fd. Если бы /dev/stdin и дружественные устройства были бы в ранних версиях Unix, как это упростило бы код для программы V7 cat? (Во многих других современных системах Unix есть каталог или файловая система /dev/fd. Если вы не используете GNU/Linux, посмотрите, что вы можете обнаружить в своей версии Unix.)

4. Даже если вы пока этого не понимаете, постарайтесь скопировать сегмент кода из V7 cat.c, который использует struct stat и функцию fstat(), в ch04-cat.c, чтобы она также сообщала об ошибке для 'cat file >> file'.

5. (Простое) Предположив наличие strerror(), напишите свою версию perror().

6. Каков результат выполнения 'ulimit -n' на вашей системе?

7. Напишите простую версию программы umask, назвав ее myumask, которая принимает в командной строке восьмеричную маску. Используйте strtol() с основанием 8 для преобразования строки символов аргумента командной строки в целое значение. Измените umask с помощью системного вызова umask().

Откомпилируйте и запустите myumask, затем проверьте значение umask с помощью стандартной команды umask. Объясните результаты. (Подсказка: в оболочке Bash введите 'type umask'.)

8. Измените простую программу copy, которую вы написали ранее, для использования open() с флагом O_SYNC. Используя команду time, сравните характеристики первоначальной и новой версии большого файла.

9. Мы сказали, что для ftruncate() файл должен быть открыт для записи. Как можно открыть файл для записи, когда у самого файла нет доступа записи?

10. Напишите программу truncate, которая используется следующим образом: 'truncate длина_файла'.

Глава 5 Каталоги и служебные данные файлов

Данная глава продолжает подъем по кривой обучения до следующего плато: понимания каталогов и информации о файлах.

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

5.1. Просмотр содержимого каталога

Все 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 <sys/types.h> как '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. Прямые ссылки

Когда файл создается с помощью open() или creat(), система находит не использующийся индекс и присваивает его новому файлу. Она создает для файла элемент каталога с именем файла и номером индекса. Опция -i команды ls отображает номер индекса.

$ echo hello, world > message /* Создать новый файл */

$ ls -il message /* Показать также номер индекса */

228786 -rw-r--r-- 1 arnold devel 13 May 4 15:43 message

Поскольку элементы каталога связывают имена файлов с индексами, у одного файла может быть несколько имен. Каждый элемент каталога, ссылающийся на один и тот же индекс, называется ссылкой (link) или прямой ссылкой (hard link) на файл. Ссылки создаются с помощью команды ln. Она используется следующим образом: 'ln старый_файл новый_файл'.

$ ln message msg /* Создать ссылку */

$ cat msg /* Показать содержание нового имени */

hello, world

$ ls -il msg message /* Показать номера индексов */

228786 -rw-r--r-- 2 arnold devel 13 May 4 15:43 message

228786 -rw-r--r-- 2 arnold devel 13 May 4 15:43 msg

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

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

$ echo "Hi, how ya doin' ?" > msg /* Изменить файл через новое имя */

$ cat message /* Показать содержание через старое имя */

Hi, how ya doin' ?

$ ls -il message msg /* Отобразить сведения. Размер изменился */

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

228786 -rw-r--r-- 2 arnold devel 19 May 4 15:51 msg

Хотя мы создали две ссылки на один файл в одном каталоге, прямые ссылки не обязательно должны находиться в одном и том же каталоге; они могут находиться в любом каталоге в той же самой файловой системе. (Несколько подробнее это обсуждается в разделе 5.1.6 «Символические ссылки».)

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

После удаления ссылки создание еще одного файла с прежним именем создает новый файл:

$ rm message /* Удалить старое имя */

$ echo "What's happenin?" > message /* Повторно использовать имя */

$ ls -il msg message /* Отобразить сведения */

228794 -rw-r--r-- 1 arnold devel 17 May 4 15:58 message

228786 -rw-r--r-- 1 arnold devel 19 May 4 15:51 msg

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

#include <unistd.h> /* POSIX */

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

При успешном создании ссылки возвращается 0, в противном случае (-1), при этом errno отражает ошибку. Важным-случаем ошибки является тот, когда newpath уже существует. Система не удалит его для вас, поскольку попытка сделать это может вызвать несовместимости в файловой системе.

5.1.3.1. Программа GNU link

Программа ln сложная и большая. Однако, GNU Coreutils содержит несложную программу link, которая просто вызывает link() со своими двумя аргументами. Следующий пример показывает код из файла link.с, не относящиеся к делу части удалены. Номера строк относятся к действительному файлу.

20  /* Обзор реализации:

21

22     Просто вызывает системную функцию 'link' */

23

    /* ...Операторы #include для краткости опущены... */

34

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

36  #define PROGRAM_NAME "link"

37

38  #define AUTHORS "Michael Stone"

39

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

41  char *program_name;

42

43  void

44  usage(int status)

45  {

     /*  ... для краткости опущено... */

62  }

63

64  int

65  main(int argc, char **argv)

66  {

67   program_name = argv[0];

68   setlocale(LC_ALL, "");

69   bindtextdomain(PACKAGE, LOCALEDIR);

70   textdomain(PACKAGE);

71

72   atexit(close_stdout);

73

74   parse_long_options(argc, argv, PROGRAM_NAME, GNU_PACKAGE,

75    VERSION, AUTHORS, usage);

76

77   /* Вышеприведенное обрабатывает --help и --version.

78      Поскольку других вызовов getopt нет, обработать здесь '--'. */

79   if (1 < argc && STREQ(argv[1], "--"))

80   {

81    --argc;

82    ++argv;

83   }

84

85   if (argc < 3)

86   {

87    error(0, 0, _("too few arguments"));

88    usage(EXIT_FAILURE);

89   }

90

91   if (3 < argc)

92   {

93    error(0, 0, _("too many arguments"));

94    usage(EXIT_FAILURE);

95   }

96

97   if (link(argv[1], argv[2]) != 0)

98    error(EXIT_FAILURE, errno, _("cannot create link %s to %s"),

99     quote_n(0, argv[2]), quote_n(1, argv[1]));

100

101  exit(EXIT_SUCCESS);

102 }

Строки 67–75 являются типичным шаблоном Coreutils, устанавливающими интернациональные настройки, выход по завершении и анализ аргументов. Строки 79–95 гарантируют, что link вызывается лишь с двумя аргументами. Сам системный вызов link() осуществляется в строке 97 (Функция quote_n() обеспечивает отображение аргументов в стиле, подходящем для текущей локали; подробности сейчас несущественны.)

5.1.3.2. Точка и точка-точка

Завершая обсуждение ссылок, давайте взглянем на то, как обрабатываются специальные имена '.' и '..'. На самом деле они просто являются прямыми ссылками. В первом случае '.' является прямой ссылкой на каталог, содержащий ее, а '..' — прямой ссылкой на родительский каталог. Операционная система создает для вас эти ссылки; как упоминалось ранее, код уровня пользователя не может создать прямую ссылку на каталог. Этот пример иллюстрирует ссылки:

$ pwd /* Отобразить текущий каталог */

/tmp

$ ls -ldi /tmp /* Показать номер его индекса */

225345 drwxrwxrwt 14 root root 4096 May 4 16:15 /tmp

$ mkdir x /* Создать новый каталог */

$ ls -ldi x /* И показать номер его индекса */

52794 drwxr-xr-x 2 arnold devel 4096 May 4 16:27 x

$ ls -ldi x/. x/.. /* Показать номера индексов . И .. */

52794 drwxr-xr-x 2 arnold devel 4096 May 4 16:27 x/.

225345 drwxrwxrwt 15 root root 4096 May 4 16:27 x/..

Родительский каталог корневого каталога (/..) является особым случаем; мы отложим его обсуждение до главы 8 «Файловые системы и обход каталогов».

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

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

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

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

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

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

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

#include <stdio.h> /* ISO С */

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

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

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

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

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

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

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

Системный вызов называется unlink():

#include <unistd.h> /* POSIX */


int unlink(const char *pathname);

В нашем обсуждении ссылок на файлы имя имеет смысл; этот вызов удаляет данную ссылку (элемент каталога) для файла. Она возвращает 0 в случае успеха и -1 при ошибке. Возможность удаления файла требует права записи лишь для каталога, а не для самого файла. Этот факт может сбивать с толку, особенно начинающих пользователей Linux/Unix. Однако, поскольку операция в каталоге одна, это имеет смысл; меняется именно содержимое каталога, а не содержимое файла[52].

5.1.5.1. Удаление открытых файлов

С самых первых дней Unix было возможно удалять открытые файлы. Просто вызовите unlink() с именем файла после успешного вызова open() или creat().

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

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

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

/* Получение конфиденциального временного хранилища,

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

int fd;

mode_t mode = O_CREAT | O_EXCL | O_TRUNC | O_RDWR;

fd = open("/tmp/myfile", mode, 0000); /* Открыть файл */

unlink("/tmp/myfile"); /* Удалить его */

/* ... продолжить использование файла... *

close(fd); /* Закрыть файл, освободить память */

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

5.1.5.2. Использование ISO С: remove()

ISO С предоставляет для удаления файлов функцию remove(); она предназначена в качестве обшей функции, годной для любой системы, поддерживающей ISO С, а не только для Unix и GNU/Linux:

#include <stdio.h> /* ISO С */


int remove(const char *pathname);

Хотя технически это не системный вызов, возвращаемое значение в том же стиле: 0 в случае успеха и -1 при ошибке, причем errno содержит значение ошибки.

В GNU/Linux remove() использует для удаления файлов системный вызов unlink(), а для удаления каталогов — системный вызов rmdir() (обсуждаемый далее в главе). (На более старых системах GNU/Linux, не использующих GLIBC, remove() является псевдонимом для unlink(); поэтому для каталогов завершается неудачей. Если у вас такая система, вам, возможно, следует ее обновить.)

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 <unistd.h> /* 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

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

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

5.2. Создание и удаление каталогов

Создание и удаление каталогов просто. Двумя системными вызовами, что неудивительно, являются mkdir() и rmdir() соответственно:

#include <sys/types.h> /* POSIX */

#include <sys/stat.h>


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


#include <unistd.h> /* POSIX */


int rmdir(const char *pathname);

Оба возвращают 0 при успехе и (-1) при ошибке, с соответствующим errno. Аргумент mode для mkdir() представляет права доступа, которые должны быть использованы для каталога. Он полностью идентичен аргументам mode для creat() и open(), обсуждавшимся в разделе 4.6 «Создание файлов».

Обе функции обрабатывают '.' и '..' в создаваемом или удаляемом каталоге. Перед удалением каталог должен быть пуст; если это не так, errno устанавливается в ENOTEMPTY. (В данном случае, «пуст» означает, что каталог содержит только '.' и '..'.)

Новым каталогам, как и всем файлам, присваивается идентификационный номер группы. К сожалению, его работа запутана. Мы отложим обсуждение до раздела 11.5.1 «Группа по умолчанию для новых файлов и каталогов».

Обе функции работают на одном уровне каталога за раз. Если /somedir существует, a /somedir/sub1 нет, 'mkdir("/somedir/sub1/sub2")' завершится неудачей. Каждый компонент в длинном пути должен создаваться отдельно (в соответствии с опцией -р mkdir, см. mkdir(1)).

Также, если pathname завершается символом '/', на некоторых системах mkdir() и rmdir() потерпят неудачу, а на других нет. Следующая программа, ch05-trymkdir.с, демонстрирует оба аспекта.

1  /* ch05-trymkdir.c --- Демонстрирует поведение mkdir().

2     Любезность Nelson H.F. Beebe. */

3

4  #include <stdio.h>

5  #include <stdlib.h>

6  #include <errno.h>

7

8  #if !defined(EXIT_SUCCESS)

9  #define EXIT_SUCCESS 0

10 #endif

11

12 void do_test(const char *path)

13 {

14  int retcode;

15

16  errno = 0;

17  retcode = mkdir(path, 0755);

18  printf("mkdir(\"%s\") returns %d: errno = %d [%s)\n",

19   path, retcode, errno, strerror(errno));

20 }

21

22 int main(void)

23 {

24  do_test("/tmp/t1/t2/t3/t4"); /*Попытка создания в подкаталоге*/

25  do_test("/tmp/t1/t2/t3");

26  do_test("/tmp/t1/t2");

27  do_test("/tmp/t1");

28

29  do_test("/tmp/u1"); /* Создать подкаталоги */

30  do_test("/tmp/u1/u2");

31  do_test("/tmp/u1/u2/u3");

32  do_test("/tmp/u1/u2/u3/u4");

33

34  do_test("/tmp/v1/"); /* Как обрабатывается завершающий '/'? */

35  do_test("/tmp/v1/v2/");

36  do_test("/tmp/v1/v2/v3/");

37  do_test("/tmp/v1/v2/v3/v4/");

38

39  return(EXIT_SUCCESS);

40 }

Вот результаты для GNU/Linux:

$ ch05-trymkdir

mkdir("/tmp/t1/t2/t3/t4") returns -1: errno = 2 [No such file or directory)

mkdir("/tmp/t1/t2/t3") returns -1: errno = 2 [No such file or directory)

mkdir("/tmp/t1/t2") returns -1: errno = 2 [No such file or directory]

mkdir("/tmp/t1") returns 0: errno = 0 [Success]

mkdir("/tmp/u1") returns 0: errno = 0 [Success]

mkdir("/tmp/u1/u2") returns 0: errno = 0 [Success]

mkdir("/tmp/u1/u2/u3") returns 0: errno = 0 [Success]

mkdir("/tmp/u1/u2/u3/u4") returns 0: errno = 0 [Success]

mkdir("/tmp/v1/") returns 0: errno = 0 [Success]

mkdir("/tmp/v1/v2/") returns 0: errno = 0 (Success]

mkdir("/tmp/v1/v2/v3/") returns 0: errno = 0 [Success]

mkdir("/tmp/v1/v2/v3/v4/") returns 0: errno = 0 [Success]

Обратите внимание, как GNU/Linux принимает завершающий слеш. Не все системы так делают.

5.3. Чтение каталогов

В оригинальных системах Unix чтение содержимого каталогов было просто. Программа открывала каталог с помощью open() и непосредственно читала двоичные структуры struct direct, по 16 байтов за раз. Следующий фрагмент кода из программы V7 rmdir[53], строки 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. Базовое чтение каталогов

Элементы каталогов представлены struct dirent (не то же самое, что V7 struct direct!):

struct dirent {

 ...

 ino_t d_ino;      /* расширение XSI --- см. текст */

 char d_name[...]; /* О размере этого массива см. в тексте */

 ...

};

Для переносимости POSIX указывает лишь поле d_name, которое является завершающимся нулем массивом байтов, представляющим часть элемента каталога с именем файла. Размер d_name стандартом не указывается, кроме того, что там перед завершающим нулем может быть не более NAME_MAX байтов. (NAME_MAX определен в <limits.h>.) Расширение XSI POSIX предусматривает поле номера индекса d_ino.

На практике, поскольку имена файлов могут быть различной длины, a NAME_MAX обычно довольно велико (подобно 255), struct dirent содержит дополнительные члены, которые помогают вести на диске учет элементов каталогов с переменными длинами. Эти дополнительные члены не существенны для обычного кода.

Следующие функции предоставляют интерфейс чтения каталогов:

#include <sys/types.h> /* POSIX */

#include <dirent.h>


DIR *opendir(const char *name);   /* Открыть каталог для чтения */

struct dirent *readdir(DIR *dir); /* Вернуть struct dirent за раз */

int closedir(DIR *dir);           /* Закрыть открытый каталог */

void rewinddir(DIR *dirp);        /* Вернуться в начало каталога */

Тип DIR является аналогом типа FILE в <stdio.h>. Это непрозрачный тип, что означает, что код приложения не должен знать, что находится внутри него; его содержимое предназначено для использования другими процедурами каталогов. Если opendir() возвращает NULL, именованный каталог не может быть открыт для чтения, а errno содержит код ошибки.

Открыв переменную DIR*, можно использовать ее для получения указателя на struct dirent, представляющего следующий элемент каталога. readdir() возвращает NULL, если достигнут конец каталога[54] или произошла ошибка.

Наконец, closedir() является аналогичной функции fclose() в <stdio.h>; она закрывает открытую переменную DIR*. Чтобы начать с начала каталога, можно использовать функцию rewinddir().

Имея в распоряжении (или по крайней мере в библиотеке С) эти функции, мы можем написать небольшую программу catdir, которая «отображает» содержимое каталога. Такая программа представлена в ch05-catdir.с:

1  /* ch05-catdir.с - Демонстрация opendir(), readdir(), closedir(). */

2

3  #include <stdio.h> /* для printf() и т.д. */

4  #include <errno.h> /* для errno */

5  #include <sys/types.h> /* для системных типов */

6  #include <dirent.h> /* для функций каталога */

7

8  char *myname;

9  int process(char *dir);

10

11 /* main --- перечисление аргументов каталога */

12

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

14 {

15  int i;

16  int errs = 0;

17

18  myname = argv[0];

19

20  if (argc == 1)

21   errs = process("."); /* по умолчанию текущий каталог */

22  else

23   for (i = 1; i < argc; i++)

24    errs += process(argv[i]);

25

26  return (errs != 0);

27 }

Эта программа вполне подобна ch04-cat.c (см. раздел 4.2 «Представление базовой структуры программы»); функция main() почти идентична. Главное различие в том, что по умолчанию используется текущий каталог, если нет аргументов (строки 20–21).

29 /*

30  * process --- сделать что-то с каталогом, в данном случае,

31  * вывести пары индекс/имя в стандартный вывод.

32  * Возвращает 0, если все OK, иначе 1.

33  */

34

35 int

36 process(char *dir)

37 {

38  DIR *dp;

39  struct dirent *ent;

40

41  if ((dp = opendir(dir)) == NULL) {

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

43   myname, dir, strerror(errno));

44   return 1;

45  }

46

47  errno = 0;

48  while ((ent = readdir(dp)) != NULL)

49   printf("%8ld %s\n", ent->d_ino, ent->d_name);

50

51  if (errno != 0) {

52   fprintf(stderr, "%s: %s: reading directory entries: %s\n",

53   myname, dir, strerror(errno));

54   return 1;

55  }

56

57  if (closedir(dp) != 0) {

58   fprintf(stderr, "%s: %s: closedir: %s\n",

59    myname, dir, strerror(errno));

60   return 1;

61  }

62

63  return 0;

64 }

Функция process() делает всю работу и большую часть кода проверки ошибок. Основой функции являются строки 48 и 49:

while ((ent = readdir(dp)) != NULL)

printf("%8ld %s\n", ent->d_ino, ent->d_name);

Этот цикл читает элементы каталога, по одной за раз, до тех пор, пока readdir() не возвратит NULL. Тело цикла отображает для каждого элемента номер индекса и имя файла. Вот что происходит при запуске программы:

$ ch05-catdir /* По умолчанию текущий каталог */

639063 .

639062 ..

639064 proposal.txt

639012 lightsabers.url

688470 code

638976 progex.texi

639305 texinfo.tex

639007 15-processes.texi

639011 00-preface.texi

639020 18-tty.texi

638980 Makefile

639239 19-i18n.texi

...

Вывод никаким образом не сортируется; он представляет линейное содержимое каталога. (Как сортировать содержимое каталога мы опишем в разделе 6.2 «Функции сортировки и поиска»).

5.3.1.1. Анализ переносимости

Есть несколько соображений по переносимости. Во-первых, не следует предполагать, что двумя первыми элементами, возвращаемыми readdir(), всегда будут '.' и '..'. Многие файловые системы используют организацию каталогов, которые отличаются от первоначального дизайна Unix, и '.' и '..' могут быть в середине каталога или даже вовсе не присутствовать[55].

Во-вторых, стандарт POSIX ничего не говорит о возможных значениях d_info. Он говорит, что возвращенные структуры представляют элементы каталогов для файлов; это предполагает, что readdir() не возвращает пустые элементы, поэтому реализация GNU/Linux readdir() не беспокоится с возвратом элементов, когда 'd_ino == 0'; она переходит к следующему действительному элементу.

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

Наконец, некоторые системы используют d_fileno вместо d_ino в struct dirent. Знайте об этом, когда нужно перенести на такие системы код, читающий каталоги.

Косвенные системные вызовы

«Не пробуйте это дома, дети!»

- М-р Wizard -

Многие системные вызовы, такие, как open(), read() и write(), предназначены для вызова непосредственно из кода пользователя: другими словами, из кода, который пишете вы как разработчик GNU/Linux.

Однако, другие системные вызовы существуют лишь для того, чтобы дать возможность реализовать стандартные библиотечные функции более высокого уровня, и никогда не должны вызываться непосредственно. Одним из таких системных вызовов является GNU/Linux getdents(); он читает несколько элементов каталога в буфер, предоставленный вызывающим — в данном случае, кодом реализации readdir(). Затем код readdir() возвращает действительные элементы каталога, по одному за раз, пополняя при необходимости буфер.

Эти системные вызовы только-для-библиотечного-использования можно отличить от вызовов для-использования-пользователем по их представлению в странице справки. Например, из getdents(2).

ИМЯ

  getdents - получить элементы каталога

ОПИСАНИЕ

  #include <unistd.h>

  #include <linux/types.h>

  #include <linux/dirent.h>

  #include <linux/unistd.h>

  _syscall3(int, getdents, uint, fd, struct dirent*,

            dirp, uint, count);

  int getdents(unsigned int fd, struct dirent *dirp,

               unsigned int count);

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

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

5.3.1.2. Элементы каталогов Linux и BSD

Хотя мы только что сказали, что вам следует использовать лишь члены d_ino и d_name структуры struct dirent, стоит знать о члене d_type в struct dirent BSD и Linux. Это значение unsigned char, в котором хранится тип файла, имя которого находится в элементе каталога:

struct dirent {

 ...

 ino_t d_ino;          /* Как ранее */

 char d_name[...];     /* Как ранее */

 unsigned char d_type; /* Linux и современная BSD */

 ...

};

d_type может принимать любые значения, описанные в табл. 5.1.


Таблица 5.1. Значения для d_type

Имя Значение
DT_BLK Файл блочного устройства
DT_CHR Файл символьного устройства
DT_DIR Каталог
DT_FIFO FIFO или именованный канал
DT_LNK Символическая ссылка
DT_REG Обычный файл
DT_SOCK Сокет
DT_UNKNOWN Неизвестный тип файла
DT_WHT Нет элемента (только системы BSD)

Знание типа файла просто путем чтения элемента каталога очень удобно; это может сэкономить на возможно дорогом системном вызове stat(). (Вызов stat() вскоре будет описан в разделе 5.4.2 «Получение информации о файле».)

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

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

#include <dirent.h> /* XSI */

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


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

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

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

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

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

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

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

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

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

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

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

Каталоги

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

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

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

Устройства

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

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

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

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

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

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

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

Сокеты

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

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

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

#include <sys/types.h> /* POSIX */

#include <sys/stat.h>

#include <unistd.h>


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, объявленной в <sys/stat.h>. Как в случае с 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 в <sys/param.h>. Эта константа не стандартизована, но довольно широко используется в системах 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 закодированы как тип файла, так и права доступа к нему. <sys/stat.h> определяет ряд макросов, которые определяют тип файла. В частности, эти макросы возвращают true или false при использовании с полем st_mode. У каждого описанного ранее типа файла есть свой макрос. Предположим, выполняется следующий код:

struct stat stbuf;

char filename[PATH_МАХ]; /* PATH_MAX из <limits.h> */

/* ... поместить имя файла в 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) ...

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


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

Маска Значение Комментарий
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_ISxxx().

5.4.4.1. Сведения об устройстве

Стандарт POSIX не определяет значение типа dev_t, поскольку предполагалось его использование на не-Unix системах также, как на Unix-системах. Однако стоит знать, что находится в dev_t.

Когда истинно S_ISBLK(sbuf.st_mode) или S_ISCHR(sbuf.st_mode), сведения об устройстве находятся в поле sbuf.st_rdev. В противном случае это поле не содержит никакой полезной информации.

Традиционно файлы устройств Unix кодируют старший и младший номера устройства в значении dev_t. По старшему номеру различают тип устройства, такой, как «дисковый привод» или «ленточный привод». Старшие номера различают также разные типы устройств, такие, как диск SCSI в противоположность диску IDE. Младшие номера различают устройства данного типа, например, первый диск или второй. Вы можете увидеть эти значения с помощью 'ls -l':

$ ls -l /dev/hda /dev/hda? /* Показать номера для первого жесткого диска */

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

brw-rw---- 1 root disk 3, 1 Aug 31 2002 /dev/hda1

brw-rw---- 1 root disk 3, 2 Aug 31 2002 /dev/hda2

brw-rw---- 1 root disk 3, 3 Aug 31 2002 /dev/hda3

brw-rw---- 1 root disk 3, 4 Aug 31 2002 /dev/hda4

brw-rw---- 1 root disk 3, 5 Aug 31 2002 /dev/hda5

brw-rw---- 1 root disk 3, 6 Aug 31 2002 /dev/hda6

brw-rw---- 1 root disk 3, 7 Aug 31 2002 /dev/hda7

brw-rw---- 1 root disk 3, 8 Aug 31 2002 /dev/hda8

brw-rw---- 1 root disk 3, 9 Aug 31 2002 /dev/hda9

$ ls -l /dev/null /* Показать сведения также для /dev/null */

crw-rw-rw- 1 root root 1, 3 Aug 31 2002 /dev/null

Вместо размера файла ls отображает старший и младший номера. В случае жесткого диска /dev/hda представляет диск в целом, /dev/hda1, /dev/hda2 и т.д. представляют разделы внутри диска. У них у всех общий старший номер устройства (3), но различные младшие номера устройств.

Обратите внимание, что дисковые устройства являются блочными устройствами, тогда как /dev/null является символьным устройством. Блочные и символьные устройства являются отдельными сущностями; даже если символьное устройство и блочное устройство имеют один и тот же старший номер устройства, они необязательно связаны

Старший и младший номера устройства можно извлечь из значения dev_t с помощью функций major() и minor(), определенных в <sys/sysmacros.h>:

#include <sys/types.h> /* Обычный */

#include <sys/sysmacros.h>


int major(dev_t dev);                /* Старший номер устройства */

int minor(dev_t dev);                /* Младший номер устройства */

dev_t makedev(int major, int minor); /* Создать значение dev_t */

(Некоторые системы реализуют их в виде макросов.)

Функция makedev() идет другим путем; она принимает отдельные значения старшего и младшего номеров и кодирует их в значении dev_t. В других отношениях ее использование выходит за рамки данной книги; патологически любопытные должны посмотреть mknod(2).

Следующая программа, ch05-devnum.c, показывает, как использовать системный вызов stat(), макросы проверки типа файла и, наконец, макросы major() и minor().

/* ch05-devnum.c --- Демонстрация stat(), major(), minor(). */

#include <stdio.h>

#include <errno.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <sys/sysmacros.h>


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

 struct stat sbuf;

 char *devtype;

 if (argc != 2) {

  fprintf(stderr, "usage: %s path\n", argv[0]);

  exit(1);

 }

 if (stat(argv[1], &sbuf) < 0) {

  fprintf(stderr, "%s: stat: %s\n", argv[1], strerror(errno));

  exit(1);

 }

 if (S_ISCHR(sbuf.st_mode))

  devtype = "char";

 else if (S_ISBLK(sbuf.st_mode))

  devtype = "block";

 else {

  fprintf(stderr, "%s is not a block or character device\n",

   argv[1]);

  exit(1);

 }

 printf("%s: major: %d, minor: %d\n", devtype,

  major(sbuf.st_rdev), minor(sbuf.st_rdev));

 exit(0);

}

Вот что происходит при запуске программы:

$ ch05-devnum /tmp /* Попробовать не устройство */

/tmp is not a block or character device

$ ch05-devnum /dev/null /* Символьное устройство */

char: major: 1, minor: 3

$ ch05-devnum /dev/hda2 /* Блочное устройство */

block: major: 3, minor: 2

К счастью, вывод согласуется с выводом ls, давая нам уверенность[59], что мы в самом деле написали правильный код.

Воспроизведение вывода ls замечательно и хорошо, но действительно ли это полезно? Ответ — да. Любое приложение, работающее с иерархиями файлов, должно быть способно различать различные типы файлов. Подумайте об архиваторе, таком как tar или cpio. Было бы пагубно, если бы такая программа рассматривала файл дискового устройства как обычный файл, пытаясь прочесть его и сохранить его содержимое в архиве! Или подумайте о find, которая может выполнять произвольные действия, основываясь на типе и других атрибутах файлов, с которыми она сталкивается, (find является сложной программой; посмотрите find(1), если вы с ней не знакомы.) Или даже нечто простое, как пакет, оценивающий свободное дисковое пространство, тоже должно отличать обычные файлы от всего остального.

5.4.4.2. Возвращаясь к V7 cat

В разделе 4.4.4 «Пример: Unix cat» мы обещали вернуться к программе V7 cat, чтобы посмотреть, как она использует системный вызов stat(). Первая группа строк, использовавшая ее, была такой:

31 fstat(fileno(stdout), &statb);

32 statb.st_mode &= S_IFMT;

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

34  dev = statb.st_dev;

35  ino = statb.st_ino;

36 }

Этот код теперь должен иметь смысл. В строке 31 вызывается fstat() для стандартного вывода, чтобы заполнить структуру statb. Строка 32 отбрасывает всю информацию в statb.st_mode за исключением типа файла, используя логическое AND с маской S_IFMT. Строка 33 проверяет, что используемый для стандартного вывода файл не является файлом устройства. В таком случае программа сохраняет номера устройства и индекса в dev и ino. Эти значения затем проверяются для каждого входного файла в строках 50–56.

50 fstat(fileno(fi), &statb);

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

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

53   ffig ? "-" : *argv);

54  fclose(fi);

55  continue;

56 }

Если значения st_dev и st_ino входного файла совпадают с соответствующими значениями выходного файла, cat выдает сообщение и продолжает со следующего файла, указанного в командной строке.

Проверка сделана безусловно, хотя dev и ino устанавливаются, лишь если вывод не является файлом устройства. Это срабатывает нормально из-за того, как эти переменные объявлены:

int dev, ino = -1;

Поскольку ino инициализирован значением (-1), ни один действительный номер индекса не будет ему соответствовать[60]. То, что dev не инициализирован так, является небрежным, но не представляет проблемы, поскольку тест в строке 51 требует, чтобы были равными значения как устройства, так и индекса. (Хороший компилятор выдаст предупреждение, что dev используется без инициализации: 'gcc -Wall' сделает это.)

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

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

$ tty /* Вывести имя устройства текущего терминала */

/dev/pts/3

$ cat /dev/pts/3 > /dev/pts/3 /* Копировать ввод от клавиатуры на экран */

this is a line of text /* Набираемое в строке */

this is a line of text /* cat это повторяет */

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

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

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

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

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

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

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

#include <unistd.h> /* 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 в <limits.h> */

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(), и все?» На это есть несколько причин.[61]

• 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. Смена владельца, прав доступа и времени изменения

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

5.5.1. Смена владельца файла: chown(), fchown() и lchown()

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

#include <sys/types.h> /* POSIX */

#include <unistd.h>


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 <sys/types.h> /* POSIX */

#include <sys/stat.h>


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()

Структура struct stat содержит три поля типа time_t:

st_atime  Время последнего доступа к файлу (чтение)

st_mtime  Время последнего изменения файла (запись).

st_ctime  Время последнего изменения индекса файла (например, переименования)

Значение time_t представляет время в «секундах с начала эпохи». Эпоха является Началом Времени для компьютерных систем GNU/Linux и Unix используют в качестве начала Эпохи полночь 1 января 1970 г по универсальному скоординированному времени (UTC).[62] Системы Microsoft Windows используют в качестве начала Эпохи полночь 1 января 1980 г. (очевидно, местное время).

Значения time_t иногда называют временными отметками (timestamps). В разделе 6.1 «Время и даты» мы рассмотрим, как получаются эти данные и как они используются. Пока достаточно знать, чем является значение time_t и то, что оно представляет секунды с начала Эпохи.

Системный вызов utime() позволяет изменять отметки времени доступа к файлу и его изменения:

#include <sys/types.h> /* POSIX */

#include <utime.h>


int utime(const char *filename, struct utimbuf *buf);

Структура utimbuf выглядит следующим образом:

struct utimbuf {

 time_t actime;  /* время доступа */

 time_t modtime; /* время изменения */

};

При успешном вызове возвращается 0, в противном случае возвращается -1. Если buf равен NULL, система устанавливает время доступа и время изменения равным текущему времени.

Чтобы изменить только одну временную отметку, используйте оригинальное значение из struct stat. Например.

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

struct stat sbuf;

struct utimbuf ut;

time_t now;


time(&now); /* Получить текущее время дня, см. след. главу */

stat("/some/file", &sbuf); /* Заполнить sbuf */

ut.actime = sbuf.st_atime; /* Время доступа без изменений */

ut.modtime = now - (24 * 60 * 60);

 /* Установить modtime на 24 часа позже */

utime("/some/file", &ut); /* Установить значения */

Вы можете спросить себя: «Почему может понадобиться кому-нибудь изменять времена доступа и изменения файла?» Хороший вопрос.

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

Однако, этот файл, возможно, не читался человеком в течение 10 лет. Некто, набрав 'ls -lu', что отображает время доступа (вместо времени изменения по умолчанию), увидел бы, что последний раз данный файл просматривали 10 лет назад. Поэтому программа архивации должна сохранить оригинальные значения времени доступа и изменения, прочесть файл для архивации, а затем восстановить первоначальное время с помощью utime().

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

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

ЗАМЕЧАНИЕ. В новом коде вы можете захотеть использовать вызов utimes() (обратите внимание на s в имени), который описан далее в книге, в разделе 14.3.2 «Файловое время в микросекундах: utimes()»

5.5.3.1. Подделка utime(file, NULL)

Некоторые более старые системы не устанавливают значения времени доступа и изменения равным текущему времени, когда второй аргумент utime() равен NULL. Однако код более высокого уровня (такой, как GNU touch) проще, если он может полагаться на один стандартизованный интерфейс.

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

Замещающая функция находится в файле lib/utime.c в дистрибутиве Coreutils Следующий код является версией из Coreutils 5.0. Номера строк относятся к началу файла:

24 #include <sys/types.h>

25

26 #ifdef HAVE_UTIME_H

27 # include <utime.h>

28 #endif

39

30 #include "full-write.h"

31 #include "safe-read.h"

32

33 /* Некоторые системы (даже имеющие <utime.h>) нигде не объявляют

34    эту структуру. */

35 #ifndef HAVE_STRUCT_UTIMBUF

36 struct utimbuf

37 {

38  long actime;

39  long modtime;

40 };

41 #endif

42

43 /* Эмулировать utime(file, NULL) для систем (подобных 4.3BSD),

44    которые не устанавливают в этом случае текущее время для времени

45    доступа и изменения file. Вернуть 0, если успешно, -1 если нет. */

46

47 static int

48 utime_null(const char *file)

49 {

50 #if HAVE_UTIMES_NULL

51  return utimes(file, 0);

52 #else

53  int fd;

54  char c;

55  int status = 0;

56  struct stat sb;

57

58  fd = open(file, O_RDWR);

59  if (fd < 0

60   || fstat(fd, &sb) < 0

61   || safe_read(fd, &c, sizeof c) == SAFE_READ_ERROR

62   || lseek(fd, (off_t)0, SEEK_SET) < 0

63   || full_write(fd, &c, sizeof c) != sizeof с

64 /* Можно сделать - это необходимо на SunOS4.1.3 с некоторой комбинацией

65    заплат, но та система не использует этот код: у нее есть utimes.

66   || fsync(fd) < 0

67    */

68   || (st.st_size == 0 && ftruncate(fd, st.st_size) < 0)

69   || close(fd) < 0)

70   status = -1;

71  return status;

72 #endif

73 }

74

75 int

76 rpl_utime(const char *file, const struct utimbuf *times)

77 {

78  if (times)

79   return utime(file, times);

80

81  return utime_null(file);

82 }

Строки 33–41 определяют структуру struct utimbuf; как сказано в комментарии, некоторые системы не объявляют эту структуру. Работу осуществляет функция utime_null(). Используется системный вызов utimes(), если он доступен (utimes() является сходным, но более развитым системным вызовом, который рассматривается в разделе 14.3.2 «Файловое время в микросекундах: utimes().» Он допускает также в качестве второго аргумента NULL, что означает использование текущего времени.)

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

1. Открыть файл, строка 58.

2. Вызвать для файла stat(), строка 60.

3. Прочесть один байт, строка 61 Для наших целей safe_read() действует подобно read(); это объясняется в разделе 10.4.4 «Повторно запускаемые системные вызовы»).

4. Переместиться обратно на начало файла с помощью lseek(), строка 62. Это сделано для записи только что прочитанного байта обратно поверх себя.

5. Записать байт обратно, строка 63. full_write() действует подобно write(); это также рассматривается в разделе 10.4.4 «Повторно запускаемые системные вызовы»).

6. Если файл имеет нулевой размер, использовать ftruncate() для установки его размера в ноль (строка 68). Это не изменяет файл, но имеет побочный эффект обновления времени доступа и изменения (ftruncate() была описана в разделе 4 8 «Установка длины файла».)

7. Закрыть файл, строка 69.

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

Функция rpl_utime() (строки 75–82) является «заместителем utime()». Если второй аргумент не равен NULL, она вызывает настоящую utime(). В противном случае она вызывает utime_null().

5.5.4. Использование fchown() и fchmod() для обеспечения безопасности

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

Однако, после открытия файла условие состязания больше не представляет проблему. Программа может использовать stat() с именем файла для получения информации о файле. Если получены сведения, которые ожидались, после открытия файла fstat() может проверить, что файл тот же самый (сравнив поля st_dev и st_ino структур struct stat «до» и «после»).

Когда программа знает, что файлы те же самые, владение или права доступа могут быть изменены с помощью fchown() или fchmod().

Эти системные вызовы, также как lchown(), сравнительно недавние;[63] в старых системах Unix их не было, хотя в современных совместимых с POSIX системах они есть.

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

5.6. Резюме

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

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

• Прямые ссылки создаются с помощью link(), символические ссылки создаются с помощью symlink(), ссылки удаляются с помощью unlink(), а переименовываются файлы (с возможным перемещением в другой каталог) с помощью rename(). Блоки данных файла не освобождаются до тех пор, пока счетчик ссылок не достигнет нуля и не закроется последний открытый дескриптор файла.

• Каталоги создаются с помощью mkdir(), а удаляются с помощью rmdir(); перед удалением каталог должен быть пустым (не оставлено ничего, кроме '.' и '..'). GNU/Linux версия функции ISO С remove() вызывает соответствующие функции unlink() или rmdir().

• Каталоги обрабатываются с помощью функций opendir(), readdir(), rewinddir() и closedir(). struct dirent содержит номер индекса и имя файла. Максимально переносимый код использует в члене d_name только имя файла. Функции BSD telldir() и seekdir() для сохранения и восстановления текущего положения в каталоге широко доступны, но не полностью переносимы, как другие функции работы с каталогами.

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

• Макрос S_ISxxx() в <sys/stat.h> дает возможность определить тип файла. Функции major() и minor() из <sys/sysmacros.h> дают возможность расшифровки значений dev_t, представляющих блочные и символьные устройства.

• Символические ссылки можно проверить, использовав lstat(), а поле st_size структуры struct stat для символической ссылки возвращает число байтов, необходимых для размещения имени указываемого файла. Содержимое символической ссылки читают с помощью readlink(). Нужно позаботиться о том, чтобы размер буфера был правильным и чтобы завершить полученное имя файла нулевым байтом, чтобы можно было его использовать в качестве строки С.

• Несколько разнообразных системных вызовов обновляют другие данные: семейство chown() используется для смены владельца и группы, процедуры chmod() для прав доступа к файлу, a utime() для изменения значений времени доступа и изменения файла.

Упражнения

1. Напишите программу 'const char *fmt_mode(mode_t mode)'. Ввод представляет собой значение mode_t, полученное из поля st_mode структуры struct stat; т.е. оно содержит как биты прав доступа, так и типа файла.

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

Когда установлены биты S_ISUID и S_IXUSR, используйте s вместо x; если установлен лишь бит I_ISUID, используйте S. То же относится к битам S_ISGID и S_IXGRP. Если установлены оба бита S_ISVTX и S_IXOTH, используйте t; для одного S_ISVTX используйте T.

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

2. Доработайте ch05-catdir.c, чтобы она вызывала stat() для каждого найденного имени файла. Затем выведите номер индекса, результат вызова fmt_mode(), число ссылок и имя файла.

3. Доработайте ch05-catdir.c так, что если файл является символической ссылкой, программа будет также выводить имя указываемого файла.

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

5. Если вы не работаете на системе GNU/Linux, запустите ch05-trymkdir (см. раздел 5.2 «Создание и удаление каталогов») на своей системе и сравните результаты с приведенными нами.

6. Напишите программу mkdir. Посмотрите свою локальную справочную страницу для mkdir(1) и реализуйте все ее опции.

7. В корневом каталоге, /, как номер устройства, так и номер индекса для '.' и '..' совпадают. Используя эту информацию, напишите программу pwd.

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

Отображение имени каталога в обратном порядке, от текущего каталога до корневого, легко. Как будет справляться ваша версия pwd с выводом имени каталога правильным образом, от корневого каталога вниз?

8. Если вы написали pwd, использовав рекурсию, напишите ее снова, использовав итерацию. Если вы использовали итерацию, напишите ее с использованием рекурсии. Что лучше? (Подсказка: рассмотрите очень глубоко вложенные деревья каталогов.)

9. Тщательно исследуйте функцию rpl_utime() (см. раздел 5.5.3.1 «Подделка utime(file, NULL)»). Какой ресурс не восстанавливается, если одна из проверок в середине if не выполняется? (Спасибо Джеффу Колье (Geoff Collyer).)

10. (Трудное) Прочтите страницу справки для chmod(1). Напишите код для анализа аргумента символических опций, который позволяет добавлять, удалять и устанавливать права доступа на основе владельца, группы, других и «всех».

Когда вы решите, что это работает, напишите свою собственную версию chmod, которая применяет назначенные права доступа к каждому файлу или каталогу, указанному в командной строке. Какую функцию вы использовали, chmod() — или open() и fchmod() — и почему?

Глава 6 Общие библиотечные интерфейсы — часть 1

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

В данной главе представлена оставшаяся часть API, необходимая для полного использования значений компонентов struct stat. Мы по порядку рассматриваем следующие темы: значения time_t для представления времени и функций форматирования времени; функции сортировки и поиска (для сортировки имен файлов или других данных); типы uid_t и gid_t для представления пользователей, групп и функций, которые сопоставляют их с соответствующими именами пользователей и групп; и наконец, функцию для проверки того, что дескриптор файла представляет терминал.

6.1. Времена и даты

Значения времени хранятся в типе, который известен как 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 <time.h> /* 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 <time.h> /* 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

Член Диапазон Значение
tm_sec 0–60 Секунда минуты. Секунда 60 предусматривает пропущенные (leap) секунды. (В C89 был диапазон 0–61.)
tm_min 0–59 Минута часа.
tm_hour 0–23 Час дня
tm_mday 1–31 День месяца
tm_mon 0–11 Месяц года
tm_year 0–N Год, начиная с 1900 г.
tm_wday 0–6 День недели, воскресенье = 0
tm_yday 0–365 День года, 1 января = 0.
tm_isdst <0, 0, >0 Флаг летнего времени.

Стандарт 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. Форматирование даты и времени

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

6.1.3.1. Простое форматирование времени: asctime() и ctime()

Две первые стандартные процедуры, перечисленные ниже, выводят данные в фиксированном формате:

#include <time.h> /* ISO С */


char *asctime(const struct tm *tm);

char *ctime(const time_t *timep);

Как и в случае с gmtime() и localtime(), asctime() и ctime() возвращают указатели на статические буфера, которые могут быть перезаписаны после каждого вызова. Более того, эти две процедуры возвращают строки в одном и том же формате. Они отличаются лишь видом принимаемых аргументов, asctime() и ctime() должны использоваться тогда, когда все, что вам нужно, это простые сведения о дате и времени.

#include <stdio.h>

#include <time.h>


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.3.2. Сложное форматирование времени: strftime()

Хотя часто достаточно использования asctime() и ctime(), у них есть также и ограничения:

• Формат вывода фиксирован. Нет способа изменить порядок элементов.

• В вывод не включаются сведения о часовом поясе.

• В выводе используются сокращенные названия месяца и дня.

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

По этим причинам C89 ввело стандартную библиотечную процедуру strftime():

#include <time.h> /* ISO С */


size_t strftime(char *s, size_t max, const char *format,

 const struct tm *tm);

strftime() сходна с sprintf(). Ее аргументы следующие:

char *s

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

size_t max

Размер буфера.

const char *format

Форматирующая строка.

const struct tm *tm

Указатель на struct tm, представляющий разложенное время, которое надо отформатировать.

Форматирующая строка содержит символы букв, смешанные о описателями преобразования, указывающими, что должно быть помещено в строку, такими, как полное имя дня недели, час в соответствии с 24-часовым или 12-часовым циклом, наличие указателей am или p.m[64], и т.д. (Вскоре будут приведены примеры.)

Если всю строку можно отформатировать с использованием не более max символов, возвращаемое значение представляет собой число символов, помещенных в s, не включая завершающий нулевой байт. В противном случае, возвращаемое значение ноль. В последнем случае содержание s «неопределенно». Следующий простой пример дает представление об использовании strftime():

#include <stdio.h>

#include <time.h>


int main(void) {

 char buf[100];

 time_t now;

 struct tm *curtime;

 time(&now);

 curtime = localtime(&now);

 (void)strftime(buf, sizeof buf,

  "It is now %A, %B %d, %Y, %I:%M %p", curtime);

 printf("%s\n", buf);

 exit(0);

}

После запуска эта программа выводит что-то типа:

It is now Thursday, May 22, 2003, 04:15 PM

В табл. 6.2 предоставлен полный список описателей преобразования, их возможные альтернативные представления и их значения. Вдобавок стандарт C99 добавил к списку дополнительные описатели; новые для C99 описатели помечены символом √.


Таблица 6.2. Описатели преобразования формата strftime()

Описатель C99 Значение
%a Локальное сокращенное название дня недели.
%A Локальное полное название дня недели.
%b Локальное сокращенное название месяца.
%B Локальное полное название месяца.
%c, %Ec Локальное «подходящее» представление даты и времени
%C, %EC Век (00–99)
%d, %Od День месяца (01–31)
%D То же, что %m/%d/%y
%e, %Oe День месяца. Одна цифра дополняется пробелом (1–31).
%F То же, что и %Y-%m-%d (формат даты ISO 8601)
%g Две последние цифры, основанной на неделе года (00–99).
%G Основанный на неделе год ISO 8601
%h То же, что и %b
%H, %OH Час в 24-часовом цикле (00–23)
%I, %OI Час в 12-часовом цикле (01–12)
%j День года (001–366)
%m, %Om Месяц в виде числа (01–12).
%M, %OM Минута в виде числа (00–59)
%n Символ конца строки ('\n')
%p Локальное обозначение a.m./p.m.
%r Локальное время в 12-часовом цикле
%R Тоже, что и %H:%M
%S, %OS Секунда в виде числа (00–60)
%t Символ табуляции ('\t')
%T То же, что и %H:%M:%S (формат ISO 8601).
%u, %Ou Число дня недели ISO 8601, понедельник = 1 (1–7).
%U, %OU Номер недели, первое воскресенье является первым днем недели 1 (00–53)
%V, %OV Номер недели ISO 8601 (01–53)
%w, %Ow День недели как число, воскресенье = 0 (0–6).
%W, %OW Номер недели, первый понедельник является первым днем недели 1 (00–53)
%x, %Ex Локальное «подходящее» представление даты
%X, %EX Локальное «подходящее» представление времени.
%y, %Ey, %Oy Две последние цифры года (00–99)
%Y, %EY Год как число.
%Z Локальный часовой пояс или отсутствие символов, если сведения о часовом поясе недоступны
%% Простой %

Локаль (locale) является способом описания местной специфики, принимая во внимание такие вещи, как язык, кодировка символов и значения по умолчанию для форматирования дат, времени, денежных сумм и т.д. Мы будем иметь с ними дело в главе 13 «Интернационализация и локализация». Пока достаточно понять, что результаты strftime() для одной и той же форматирующей строки могут быть разными в зависимости от настроек текущей локали.

Версии, начинающиеся с %E и %O, предназначены для «альтернативного представления». В некоторых локалях есть несколько способов представления одних и тех же сведений; эти описатели предоставляют доступ к дополнительным представлениям. Если определенная локаль не поддерживает альтернативного представления, strftime() использует обычную версию.

Многие Unix-версии date дают возможность предоставить в командной строке форматирующую строку, начинающуюся с символа '+'. Затем date форматирует текущие дату и время и выводит в соответствии с форматирующей строкой:

$ date + 'It is now %A, %B %d, %Y, %I:%M %p'

It is now Sunday, May 25, 2003, 06:44 PM

Большинство новых описателей C99 происходит от таких существующих реализаций date Unix. Описатели %n и %t не являются в С абсолютно необходимыми, поскольку символы табуляции и конца строки могут быть помещены в строку непосредственно. Однако в контексте форматирующей строки date для командной строки они имеют больше смысла. Поэтому они также включены в спецификацию strftime().

Стандарт ISO 8601 определяет (среди других вещей), как нумеруются недели в пределах года. В соответствии с этим стандартом недели отсчитываются с понедельника по воскресенье, а понедельник является днем недели 1, а не 0. Если неделя, в которой оказывается 1 января, содержит по крайней мере четыре дня нового года, она считается неделей 1. В противном случае, это последняя неделя предыдущего года с номером 52 или 53. Эти правила используются для вычислений описателей форматов %g, %G и %V. (Хотя ограниченным американцам, таким, как автор, эти правила могут показаться странными, они обычно повсюду используются в Европе.)

Многие из описателей стандартов дают результаты, специфичные для текущей локали. Вдобавок некоторые указывают, что они выдают «подходящее» представление для локали (например, %x). Стандарт C99 определяет значения для локали «С». Эти значения перечислены в табл. 6.3


Таблица 6.3. Значения локали «С» для определенных форматов strftime()

Описатель Значение
Первые три символа .
Один из дней Sunday, Monday, …, Saturday
%b Первые три символа
Один из месяцев January, February, …, December
То же, что и %а %b %е %T %Y
%p AM или PM
%r То же, что и %I:%M:%S %p
%x То же, что и %m/%d/%y
%X То же, что и %T.
%Z Определяется реализацией

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

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

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

char fname[PATH_МАХ]; /* PATH_МАХ находится в <limits.h> */

time_t now;

struct tm *tm;

int fd;


time(&now);

tm = localtime(&now);

strftime(fname, sizeof fname, "/var/log/myapp.%Y-%m-%d-%H:%M", tm);

fd = creat(name, 0600);

...

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

ЗАМЕЧАНИЕ. Некоторые форматы данных более полезны, чем другие. Например, 12-часовое время двусмысленно, также, как чисто числовые форматы дат. (Что означает '9/11'? Это зависит от того, где вы живете) Сходным образом, годы из двух цифр также являются плохой мыслью. Используйте strftime() благоразумно

6.1.4. Преобразование разложенного времени в time_t

Получение от системы значений «секунд с начала Эпохи» просто; именно так даты и времена хранятся в индексах и возвращаются с помощью time() и stat(). Эти значения также легко оценивать на равенство или посредством < и > для простых тестов раньше/позже.

Однако, с датами, введенными людьми, не так легко работать. Например, многие версии команды touch позволяют предусмотреть дату и время, в которое touch должна установить время модификации или доступа к файлу (с помощью utime(), как было описано в разделе 5.5.3 «Изменение отметок времени: utime()»).

Преобразование даты, введенной человеком, в значение time_t трудно: надо принять во внимание високосные годы, учесть часовые пояса и т.д. Поэтому стандарт C89 ввел функцию mktime():

#include <time.h> /* 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 <stdio.h>

4  #include <time.h>

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. Получение сведений о часовом поясе

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

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

Интерфейс языка С для сведений о часовых поясах развивался в разных версиях Unix, как на System V, так и Berkley, пока, наконец, не был стандартизован POSIX следующим образом.

#include <time.h> /* POSIX */


extern char *tzname[2];

extern long timezone;

extern int daylight;


void tzset(void);

Функция tzset() проверяет переменную окружения TZ для получения сведений о часовом поясе и переходе на летнее время.[65] Если эта переменная не установлена, tzset() использует «определенный в реализации часовой пояс по умолчанию», который скорее всего является часовым поясом машины, на которой вы работаете.

После вызова tzset() сведения о локальном часовом поясе доступны в нескольких переменных:

extern char *tzname[2]

Стандартное имя и имя летнего времени для часового пояса. Например, для областей США в восточном часовом поясе именами часового пояса являются 'EST' (Eastern Standard Time) и 'EDT' (Eastern Daylight Time).

extern long timezone

Разница в секундах между текущим часовым поясом и UTC. Стандарт не определяет, как эта разница работает. На практике отрицательные значения представляют часовые пояса восточнее (перед, или те, которые позже) UTC; положительные значения представляют часовые пояса западнее (за, или те, которые раньше) UTC. Если вы посмотрите на это значение как «насколько изменить местное время, чтобы оно стало равно UTC», тогда знак этого значения имеет смысл.

extern int daylight

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

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

Стандарт POSIX указывает, что ctime(), localtime(), mktime() и strftime() действуют, «как если бы» они вызывали tzset(). Это означает, что им в действительности не нужно вызывать tzset(), но они должны вести себя, как если бы эта функция была вызвана. (Формулировка призвана дать определенную гибкость при реализации, в то же время гарантируя правильное поведение кода уровня пользователя.)

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

6.1.5.1. Системы BSD: timezone(), не timezone

Некоторые производные от BSD 4.4 системы вместо переменной POSIX timezone предоставляют функцию timezone():

#include <time.h> /* BSD */

char *timezone(int zone, int dst);

Аргумент zone является числом минут западнее GMT, a dst истинно, если действует летнее время. Возвращаемое значение является строкой, дающей имя указанного часового пояса, или значение, выраженное относительно GMT. Эта функция обеспечивает совместимость с функцией V7 с тем же именем и поведением.

Локальное время: откуда оно известно?

Системы GNU/Linux хранят информацию о часовых поясах в файлах и каталогах в /usr/share/zoneinfo:

$ cd /usr/share/zoneinfo

$ ls -FC

Africa/     Canada/ Factory    Iceland   MST7MDT  Portugal  W-SU

America/    Chile/  GB         Indian/   Mexico/  ROC       WET

Antarctica/ Cuba    GB-Eire    Iran      Mideast/ ROK       Zulu

Arctic/     EET     GMT        Israel    NZ       Singapore iso3166.tab

Asia/       EST     GMT+0      Jamaica   NZ-CHAT  SystemV/  posix/

Atlantic/   EST5EDT GMT-0      Japan     Navajo   Turkey    posixrules

Australia/  Egypt   GMT0       Kwajalein PRC      UCT       right/

Brazil/     Eire    Greenwich  Libya     PST8PDT  US/       zone.tab

CET         Etc/    HST        MET       Pacific/ UTC

CST6CDT     Europe/ Hongkong   MST       Poland   Universal

Когда возможно, этот каталог использует прямые ссылки для предоставления одних и тех же данных с разными именами. Например, файлы EST5EDT и US/Eastern на самом деле одни и те же:

$ ls -il EST5EDT US/Eastern

724350 -rw-r--r-- 5 root root 1267 Sep б 2002 EST5EDT

724350 -rw-r--r-- 5 root root 1267 Sep 6 2002 US/Eastern

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

$ file /etc/localtime

/etc/localtime: timezone data

На нашей системе это автономная копия файла для нашего часового пояса. На других системах это может быть символическая ссылка на файл в /usr/share/zoneinfo. Преимуществом использования отдельной копии является то, что все по-прежнему работает, если /usr не смонтирован.

Переменная окружения TZ, если она установлена, перекрывает значение по умолчанию для часового пояса:

$ date /* Дата и время в часовом поясе по умолчанию

        */

Wed Nov 19 06:44:50 EST 2003

$ export TZ=PST8PDT /* Смена часового пояса на Западное

                       побережье США */

$ date /* Вывести дату и время */

Wed Nov 19 03:45:09 PST 2003

Широкое распространение этой функции делает переносимое использование переменной POSIX timezone трудной. К счастью, мы не видим большой потребности в ней strftime() должно быть достаточно едва ли не для большинства необычных потребностей

6.2. Функции сортировки и поиска

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

Все процедуры разделяют общий лейтмотив; данные управляются через указатели void*, а сортировку осуществляют предоставленные пользователем функции. Обратите также внимание, что эти API применяются к данным в памяти. Структуры сортировки и поиска в файлах значительно более сложны и выходят за рамки вводного руководства, подобного данному. (Однако, команда sort хорошо работает для текстовых файлов; см. справочную страницу для sort(1). Сортировка двоичных файлов требует написания специальной программы.)

Поскольку ни один алгоритм не работает одинаково хорошо для всех приложений, имеются несколько различных наборов библиотечных процедур для сопровождения искомых коллекций данных. Данная глава рассматривает лишь один простой интерфейс для поиска. Другой, более развитый интерфейс описан в разделе 14.4 «Расширенный поиск с использованием двоичных деревьев». Более того, мы намеренно не объясняем лежащие в основе алгоритмы, поскольку данная книга об API, а не об алгоритмах и структурах данных. Важно понять, что API можно рассматривать как «черные ящики», выполняющие определенную работу без необходимости понимания подробностей их работы.

6.2.1. Сортировка: qsort()

Сортировка выполняется с помощью qsort():

#include <stdlib.h> /* ISO С */


void qsort(void *base, size_t nmemb, size_t size,

 int (*compare)(const void*, const void*));

Название qsort() происходит от алгоритма машинного поиска Хоара Quicksort (C.A.R. Hoare's Quicksort algorithm), который использовался в первоначальной реализации Unix. (Ничто в стандарте POSIX не требует использования этого алгоритма для qsort(). Реализация GLIBC использует высоко оптимизированную комбинацию Quicksort и Insertion Sort.)

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

void *base

Адрес начала массива.

size_t nmemb

Общее число элементов в массиве.

size_t size

Размер каждого элемента массива. Лучший способ получения этого значения — оператор С sizeof.

int (*compare)(const void*, const void*)

Возможно устрашающее объявление указателя функции. Оно говорит, что «compare указывает на функцию, которая принимает два параметра 'const void*' и возвращает int».

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

int dcomp(const void *d1p, const void *d2p) {

 const double *d1, *d2;

 d1 = (const double*)d1p; /* Привести указатели к нужному типу */

 d2 = (const double*)d2p;

 if (*d1 < *d2) /* Сравнить и вернуть нужное значение */

  return -1;

 else if (*d1 > *d2)

  return 1;

 else if (*d1 == *d2)

  return 0;

 else

  return -1; /* NaN сортируется до действительных чисел */

}

Это показывает общий стереотип для функций сравнения: привести тип аргументов от void* к указателям на сравниваемый тип, а затем вернуть результат сравнения.

Для чисел с плавающей точкой простое вычитание, подобное 'return *d1 - *d2', не работает, особенно если одно значение очень маленькое или одно или оба значения являются специальными значениями «не число» или «бесконечность». Поэтому нам приходится осуществлять сравнение вручную, принимая во внимание нечисловое значение (которое даже не равно самому себе!)

6.2.1.1. Пример: сортировка сотрудников

Для более сложных структур требуются более сложные функции. Например, рассмотрите следующую (довольно тривиальную) struct employee:

struct employee {

char lastname[30];

char firstname[30];

long emp_id;

time_t start_date;

};

Мы могли бы написать функцию для сортировки сотрудников по фамилии, имени и идентификационному номеру:

int emp_name_id_compare(const void *e1p, const void *e2p) {

 const struct employee *e1, *e2;

 int last, first;

 e1 = (const struct employee*)e1p; /* Преобразовать указатели */

 e2 = (const struct employee*)e2p;

 if ((last = strcmp(e1->lastname, e2->lastname)) != 0)

  /* Сравнить фамилии */

  return last; /* Фамилии различаются */

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

 if ((first = strcmp(e1->firstname, e2->firstname)) != 0)

  /* Сравнить имена */

  return first; /* Имена различаются */

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

 if (e1->emp_id < e2->emp_id) /* Сравнить ID сотрудника */

  return -1;

 else if (e1->emp_id == e2->emp_id)

  return 0;

 else

  return 1;

}

Логика здесь проста: сначала сравниваются фамилии, затем имена, а затем номера ID, если два имени совпадают. Используя для строк strcmp(), мы автоматически получаем правильное отрицательное/нулевое/положительное значение для возвращения.

При сравнении ID сотрудников нельзя просто использовать вычитание: представьте, что long 64-разрядный, а int 32-разрядный, а два значения отличаются лишь в старших 32 битах (скажем, младшие 32 бита равны нулю). В таком случае вычитание автоматически привело бы к приведению типа к int с отбрасыванием старших 32 битов и возвращением неверного результата.

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

Это важный момент qsort() не гарантирует стабильной сортировки. Стабильна сортировка, в которой, если два элемента равны на основе значения какого-либо ключа(-ей), они сохраняют свой первоначальный порядок друг относительно друга в конечном отсортированном массиве. Например, рассмотрите трех сотрудников с одинаковыми фамилиями и именами и с номерами 17, 42 и 81. Их порядок в первоначальном массиве. возможно, был 42, 81 и 17 (Что означает, что сотрудник 42 находится по индексу с меньшим значением, чем сотрудник 81, который, в свою очередь, находится по индексу с меньшим значением, чем сотрудник 17). После сортировки порядок может оказаться 81, 42 и 17. Если ото представляет проблему, процедура сравнения должна рассматривать все важные ключевые значения (Наша так и делает.)

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

int emp_seniority_compare(const void *e1p,

 const void *e2p) {

 const struct employee *e1, *e2;

 double diff;

 /* Привести указатели к нужному типу */

 e1 = (const struct employee*)e1p;

 e2 = (const struct employee*)e2p;

 /* Сравнить времена */

 diff = difftime(e1->start_date, e2->start_date);

 if (diff < 0)

  return -1;

 else if (diff > 0)

  return 1;

 else

  return 0;

}

Для максимальной переносимости мы использовали difftime(), которая возвращает разницу в секундах между двумя значениями time_t. Для данного конкретного случая приведение, такое, как

return (int)difftime(e1->start_date, e2->start_date);

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

Вот пример файла данных со списком пяти президентов США:

$ cat presdata.txt

/* Фамилия, имя, номер президента, инаугурация */

Bush George 43 980013600

Clinton William 42 727552800

Bush George 41 601322400

Reagan Ronald 40 348861600

Carter James 39 222631200

В ch06-sortemp.c приведена простая программа, которая считывает этот файл в массив struct employee, а затем сортирует его, используя две только что представленные функции сравнения.

1   /* ch06-sortemp.c --- Демонстрирует qsort() с двумя функциями сравнения. */

2

3   #include <stdio.h>

4   #include <stdlib.h>

5   #include <time.h>

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_name_id_compare --- сравнение по имени, затем no ID */

15

16  int emp_name_id_compare(const void *e1p, const void *e2p)

17  {

     /* ...как показано ранее, опущено для экономии места... */

39  }

40

41  /* emp_seniority_compare --- сравнение по старшинству */

42

43  int emp_seniority_compare(const void *e1p, const void *e2p)

44  {

     /* ...как показано ранее, опущено для экономии места... */

58  }

59

60  /* main --- демонстрация сортировки */

61

62  int main(void)

63  {

64   #define NPRES 10

65   struct employee presidents[NPRES];

66   int i, npres;

67   char buf[BUFSIZ];

68

69   /* Очень простой код для чтения данных: */

70   for (npres = 0; npres < NPRES && fgets(buf, BUFSIZ, stdin) != NULL;

71    npres++) {

72    sscanf(buf, "%s %s %ld %ld\n",

73     presidents[npres].lastname,

74     presidents[npres].firstname,

75     &presidents[npres].emp_id,

76     &presidents[npres].start_date);

77   }

78

79   /* npres теперь содержит число прочитанных строк. */

80

81   /* Сначала сортировка по имени */

82   qsort(presidents, npres, sizeof(struct employee), emp_name_id_compare);

83

84   /* Вывести результат */

85   printf("Sorted by name:\n");

86   for (i = 0; i < npres; i++)

87    printf("\t%s %s\t%d\t%s",

88     presidents[i].lastname,

89     presidents[i].firstname,

90     presidents[i].emp_id,

91     ctime(&presidents[i].start_date));

92

93   /* Теперь сортировка по старшинству */

94   qsort(presidents, npres, sizeof(struct employee), emp_seniority_compare);

95

96   /* И снова вывести */

97   printf("Sorted by seniority:\n");

98   for (i = 0; i < npres; i++)

99    printf("\t%s %s\t%d\t%s",

100    presidents[i].lastname,

101    presidents!i].firstname,

102    presidents[i].emp_id,

103    ctime(&presidents[i].start_date));

104 }

Строки 70–77 считывают данные. Обратите внимание, что любое использование scanf() требует от входных данных «хорошего поведения». Если, например, какое-нибудь имя содержит более 29 символов, возникает проблема. В данном случае, мы вне опасности, но в коде изделия нужно быть гораздо более осмотрительным.

Строка 82 сортирует данные по имени и по ID сотрудника, а затем строки 84–91 выводят отсортированные данные. Сходным образом строка 94 пересортировывает данные, на этот раз по старшинству, а строки 97–103 выводят результаты. После компилирования и запуска программа выдает следующие результаты:

$ ch06-sortemp < presdata.txt

Sorted by name:

  Bush George 41 Fri Jan 20 13:00:00 1989

  Bush George 43 Sat Jan 20 13:00:00 2001

  Carter James 39 Thu Jan 20 13:00:00 1977

  Clinton William 42 Wed Jan 20 13:00:00 1993

  Reagan Ronald 40 Tue Jan 20 13:00:00 1981 \

Sorted by seniority:

  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

(Мы использовали 1 час пополудни как приблизительное время, когда все президенты начали работать.)[66]

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

Платой за это является дополнительная память для размещения указателей и модификация функций сравнения для дополнительного перенаправления указателей при сравнении структур. Полученной выгодой может стать значительное ускорение работы, поскольку на каждом шаге перемещается лишь четырех- или восьмибайтный указатель вместо большой структуры. (Наша struct employee имеет размер по крайней мере 68 байтов. При обмене четырехбайтных указателей перемещается в 17 раз меньше данных, чем при обмене структур.) Для тысяч размещенных в памяти структур разница мажет быть существенной.

ЗАМЕЧАНИЕ. Если вы являетесь программистом С++, знайте! qsort() может быть опасной для использования с массивами объектов! qsort() осуществляет простые перемещения памяти, копируя байты. Она совершенно ничего не знает о конструкциях С++, таких, как конструкторы копирования или функции operator=(). Вместо этого используйте одну из функций сортировки STL[67] или используйте методику отдельного массива указателей.

6.2.1.2. Пример: сортировка содержимого каталога

В разделе 5.3 «Чтение каталогов» мы продемонстрировали, как элементы каталогов возвращаются в физическом порядке каталога. В большинстве случаев гораздо полезнее иметь содержимое каталога отсортированным каким-нибудь образом, например, по имени или по времени изменения. Хотя и не стандартизованные POSIX, несколько процедур упрощают это, используя qsort() в качестве лежащего в основе сортирующего агента:

#include <dirent.h> /* Обычный */


int scandir(const char *dir, struct dirent ***namelist,

 int (*select)(const struct dirent*),

 int (*compare)(const struct dirent **, const struct dirent **));

int alphasort(const void *a, const void *b);

int versionsort(const void *a, const void *b); /* GLIBC */

Функции scandir() и alphasort() были сделаны доступными в 4.2 BSD и широко поддерживаются[68], versionsort() является расширением GNU.

scandir() читает каталог, имя которого дано в dir, создает с использованием malloc() массив указателей struct dirent и устанавливает *namelist, чтобы он указывал на начало этого массива. Как массив указателей, так и указываемые структуры struct dirent выделяются с помощью malloc(); вызывающий код должен использовать free(), чтобы избежать утечек памяти.

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

Указатель функции compare сравнивает два элемента каталога. Он передается функции qsort() для использования при сортировке.

alphasort() лексикографически сравнивает имена файлов. Она использует для сравнения функцию strcoll(). strcoll() похожа на strcmp(), но учитывает связанные с местной спецификой правила сортировки (см. раздел 13.4 «Не могли бы вы написать это для меня по буквам?»).

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

В ch06-sortdir.c приведена программа, похожая на ch04-catdir.c. Однако, она использует для работы scandir() и alphasort().

1  /* ch06-sortdir.c --- Демонстрирует scandir(), alphasort(). */

2

3  #include <stdio.h> /* для printf() etc. */

4  #include <errno.h> /* для errno */

5  #include <sys/types.h> /* для системных типов */

6  #include <dirent.h> /* для функций каталогов */

7

8  char *myname;

9  int process(const char *dir);

10

11 /* main --- перечислить аргументы каталога */

12

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

14 {

15  int i;

16  int errs = 0;

17

18  myname = argv[0];

19

20  if (argc == 1)

21   errs = process("."); /* по умолчанию текущий каталог */

22  else

23   for (i = 1; i < argc; i++)

24    errs += process(argv[i]);

25

26  return (errs != 0);

27 }

28

29 /* nodots --- игнорирует файлы с точкой, для scandir() */

30

31 int

32 nodots(const struct dirent *dp)

33 {

34  return (dp->d_name[0] != '.');

35 }

36

37 /*

38  * process --- сделать что-то с каталогом, в данном случае,

39  * вывести в стандартный вывод пары индекс/имя.

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

41  */

42

43 int

44 process(const char *dir)

45 {

46  DIR *dp;

47  struct dirent **entries;

48  int nents, i;

49

50  nents = scandir(dir, &entries, nodots, alphasort);

51  if (nents < 0) {

52   fprintf(stderr, "%s: scandir failed: %s\n", myname,

53    strerror(errno));

54   return 1;

55  }

56

57  for (i = 0; i < nents; i++) {

58   printf("%81d %s\n", entries[i]->d_ino, entries[i]->d_name);

59   free(entries[i]);

60  }

61

62  free(entries);

63

64  return 0;

65 }

Функция main() программы (строки 1–27) следует стандартному шаблону, который мы использовали до этого. Функция nodots() (строки 31–35) действует как параметр select, выбирая лишь имена файлов, которые не начинаются с точки.

Функция process() (строки 43–65) довольно проста, причем scandir() делает большую часть работы. Обратите внимание, как каждый элемент отдельно освобождается с помощью free() (строка 59) и как освобождается также весь массив (строка 62).

При запуске содержимое каталога в самом деле выводится в отсортированном порядке, без '.' и '..'.

$ ch06-sortdir /* Действия по умолчанию отображают текущий каталог */

2097176 00-preface.texi

2097187 01-intro.texi

2097330 02-cmdline.texi

2097339 03-memory.texi

2097183 03-memory.texi.save

2097335 04-fileio.texi

2097334 05-fileinfo.texi

2097332 06-generall.texi

...

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 <stdlib.h> /* 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 <stdio.h>

4  #include <errno.h>

5  #include <stdlib.h>

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 «Расширенный поиск с использованием двоичных деревьев».

6.3. Имена пользователей и групп

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

Ранние системы Unix хранили информацию, сопоставляющую имена с номерами ID, в простых текстовых файлах /etc/passwd и /etc/group. На современных системах эти файлы до сих пор существуют, а их формат не изменился после V7 Unix. Однако, они больше не определяют данные полностью. Большие установленные системы с множеством сетевых хостов хранят сведения в сетевых базах данных, которые представляют собой способ хранения информации на небольшом числе серверов, доступ к которым осуществляется через сеть[69]. Однако, такое использование прозрачно для большинства приложений, поскольку доступ к информации осуществляется через тот самый 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.

Доступ к базе данных пользователей осуществляется через процедуры, объявленные в <pwd.h>:

#include <sys/types.h> /* XSI */

#include <pwd.h>


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) склоняются к использованию более эффективных методов хранения, так что эти вызовы, возможно, в таком случае не такие дорогие[70].

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 для базы данных пользователей. Следующие функции определены в <grp.h>:

#include <sys/types.h> /* XSI */

#include <grp.h>


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 <stdio.h>

4  #include <sys/types.h>

5  #include <grp.h>

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

6.4. Терминалы: isatty()

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

Однако иногда бывают моменты, когда программе действительно нужно знать, с какого рода файлом связан файловый дескриптор. Семейство вызовов stat() часто предоставляет достаточно сведений обычный файл, каталог, устройство и т.д. Хотя иногда даже этого недостаточно, и для интерактивных программ, в частности, вам может потребоваться знать, не представляет ли дескриптор файла tty.

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

Различить можно с помощью isatty().

#include <unistd.h> /* POSIX */


int isacty(int desc);

Эта функция возвращает 1, если дескриптор файла desc представляет терминал, в противном случае 0. В соответствии с POSIX isatty() может установить errno для указания ошибки; поэтому до вызова isatty() следует установить errno в 0, а затем проверить ее значение, если был возвращен 0. (Справочная страница GNU/Linux isatty(3) не упоминает об использовании errno.) Стандарт POSIX также указывает, что просто возврат isatty() 1 не означает, что на другом конце дескриптора файла находится человек!

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

6.5. Рекомендуемая литература

1. Mastering Algorithms With C by Kyle Loudon. O'Reilly & Associates, Sebastopol, California, USA, 1999. ISBN: 1-56592-453-3.

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

2. The Art of Computer Programming Volume 3. Sorting and Searching, 2nd edition, by Donald E. Knuth Addison-Wesley, Reading Massachusetts, USA, 1998. ISBN: 0-201-89685-0.[71]

На эту книгу обычно ссылаются как на последнее слово в сортировке и поиске. Примите во внимание, что она значительно более сжата и труднее для чтения, чем книга Loudon'a.

3. Проект GTK+[72] состоит из нескольких совместно работающих библиотек GTK+ является лежащим в основе инструментарием, используемым проектом GNU GNOME.[73] В основе иерархии библиотек располагается Glib, библиотека фундаментальных типов, структур данных и функций для работы с ними. Glib включает возможности для всех основных операций, которые мы до сих пор рассмотрели в данной книге, и многое другое, включая связанные списки и хэш-таблицы. Для просмотра онлайн-документов начните с веб-сайта проекта документации GTK+[74], щелкните на ссылке «Загрузить» (Download) и идите дальше по онлайн-версии.

6.6. Резюме

• Время внутренне хранится в виде значений time_t, представляющих «секунды с начала Эпохи». Эпоха для систем GNU/Linux и Unix начинается с полночи 1 января 1970 г. по UTC. Текущее время получается от системы с помощью системного вызова time(), а difftime() возвращает разницу в секундах между двумя значениями time_t.

• Структура struct tm представляет «разложенное время», которое является значительно более удобным представлением даты и времени. gmtime() и localtime() преобразуют значения time_t в значения struct tm, a mktime() действует в обратном направлении.

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

• Сведения о часовом поясе доступны через вызов tzset(). Поскольку стандартные процедуры действуют так, как если бы они автоматически вызывали tzset(), необходимость в непосредственном вызове этой функции возникает редко.

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

• scandir() читает в массив struct dirent каталог целиком. Для выбора того, какие элементы включить в массив и для обеспечения упорядочения элементов в массиве могут использоваться предоставленные пользователем функции alphasort() является стандартной функцией для сортировки элементов каталога по имени; scandir() передает функцию сортировки прямо через qsort().

• Функция bsearch() работает подобно qsort(). Она осуществляет быстрый бинарный поиск. Используйте ее, если цена линейного поиска перевешивает цену сортировки ваших данных. (Дополнительный API для поиска коллекций данных описан в разделе 14.4 «Расширенный поиск с помощью двоичных деревьев».)

• Базы данных пользователей и групп могут храниться в файлах на локальном диске или могут быть доступны через сеть. Стандартный API намеренно скрывает это различие. Каждая база данных обеспечивает как линейный просмотр всей базы данных, так и непосредственные запросы имени или ID пользователя/группы.

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

Упражнения

1. Напишите простую версию команды date, которая принимает в командной строке строку формата и использует ее для форматирования и вывода текущего времени.

2. Когда файл старше шести месяцев, 'ls -l' использует для печати времени изменения более простой формат. GNU версия файла ls.c использует следующее вычисление:

3043 /* Время считается недавним, если оно в пределах последних 6

3044    месяцев. В Григорианском годе 365.2425 * 24 * 60 * 60 ==

3045    31556952 секунд в среднем. Запишите это значение как

3046    целую константу для избежания трудностей с плавающей точкой.*/

3047    six_months_ago = current_time - 31556952 / 2;

Сравните это с нашим примером вычисления шести прошлых месяцев. Каковы преимущества и недостатки каждого из методов?

3. Напишите простую версию команды touch, которая изменяет время модификации файла, имя которого указано в командной строке, на текущее время

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

5. Добавьте к своей версии touch еще одну опцию, которая принимает имя файла и использует время модификации данного файла как новое время модификации файла, указанного в командной строке.

6. Усовершенствуйте ch06-sortemp.c так, чтобы она сортировала отдельный массив указателей, указывающих на массив сотрудников.

7. Добавьте к ch06-sortdir.c опции для сортировки по номеру индекса, времени модификации, времени доступа и размеру. Добавьте «обратную опцию», так, чтобы основанная на времени сортировка первым помещала самый недавний файл, а по другим критериям (размеру, индексу) помещала вначале наибольшее значение.

8. Напишите простую версию команды chown. Она должна использоваться так:

chown пользователь[:группа] файлы ...

Здесь пользователь и группа являются именами пользователя и группы, представляющими новых пользователя и группу для указанных файлов. Группа необязательна; если она присутствует, она отделяется от пользователя двоеточием. Чтобы протестировать свою версию на системе GNU/Linux, вы должны зарегистрироваться в качестве root. Делайте это осторожно!

9. Усовершенствуйте свою chown, чтобы допустить использование числовых значений пользователя или группы наряду с их именами.

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

11. Напишите специализированную библиотеку поиска пользователей, которая считывает в динамически выделяемый массив всю базу данных пользователей. Предусмотрите быстрый поиск пользователей как по ID, так и по именам. Гарантируйте обработку случая, при котором запрошенный пользователь не найден.

12. Сделайте то же самое для базы данных групп.

13. Напишите программу stat, которая печатает содержимое struct stat для каждого файла, указанного в командной строке. Она должна выводить все значения в формате, удобном для восприятия человеком: значения time_t в виде дат и времени, значения uid_t и gid_t в виде соответствующих имен (если они доступны), а также содержимое символических ссылок. Выведите поле st_mode таким же образом, как вывела бы ls.

Сравните свою программу с программой stat GNU Coreutils как по их выводу, так и по исходному коду.

Глава 7 Соединяя все вместе: ls

Команда V7 ls хорошо связывает воедино все, что мы до сих пор видели. Она использует почти все API, которые мы рассмотрели, затрагивая многие аспекты программирования Unix: выделение памяти, вспомогательные данные файлов, времена и даты, имена пользователей, чтение каталогов и сортировку.

7.1. Опции V7 ls

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

 Выводит все элементы каталога. Без нее '.' и '..' не выводятся. Довольно интересно, V7 игнорирует лишь '.' и '..', тогда как с V1 по V6 игнорируется любой файл, имя которого начинается с точки. Это последнее является также поведением по умолчанию и для современных версий ls.

-n Вместо времени модификации файла использует для -t или -l время изменения индекса.

-d Для аргументов каталогов выводит сведения о самом каталоге, а не о его содержимом.

-f «Заставляет» читать каждый элемент как каталог и печатать найденное в каждом слоте имя. Эта опция отключает -l, -r, -s, -t и включает . (Эта опция, очевидно, существует для отладки и исправления файловой системы.)

-g Для 'ls -l' использует вместо имени пользователя имя группы.

-i Выводит в первом столбце номер индекса вместе с именем файла или длинным листингом.

-l Осуществляет привычный вывод в длинном формате. Обратите, однако, внимание, что V7 'ls -l' выводила лишь имя владельца, а не имена владельца и группы вместе.

-r Изменяет порядок сортировки, будь то по алфавиту для имен файлов или по времени.

-s Выводит размер файла в 512-байтовых блоках. Справочная страница V7 ls(1) утверждает, что вспомогательные блоки (indirect blocks) — блоки, используемые файловой системой для обнаружения блоков больших файлов — также учитываются при вычислении, но, как мы увидим, это утверждение было неверным.

-t Сортирует вывод вместо имени по времени модификации, сначала более ранние.

-u С опциями -t и/или -l использует время доступа вместо времени модификации. Наибольшие различия между V7 ls и современной ls затрагивают опцию и опцию -l. Современные системы опускают все файлы с точками, если не указана , и они включают в длинный листинг -l имена и владельца, и группы. На современных системах -g означает вывод лишь имени группы, а -o означает вывод лишь имени владельца. Стоит заметить, что у GNU ls свыше 50 опций!

7.2. Код V7 ls

Файл /usr/src/cmd/ls.c в дистрибутиве V7 содержит код. Весь он занимает 425 строк.

1  /*

2   * перечисляет файлы или каталоги

3   */

4

5  #include <sys/param.h>

6  #include <sys/stat.h>

7  #include <sys/dir.h>

8  #include <stdio.h>

9

10 #define NFILES 1024

11 FILE *pwdf, *dirf;

12 char stdbuf[BUFSIZ];

13

14 struct lbuf { /* Собирает необходимые сведения */

15  union {

16   char lname[15];

17   char *namep;

18  } ln;

19  char ltype;

20  short lnum;

21  short lflags;

22  short lnl;

23  short luid;

24  short lgid;

25  long lsize;

26  long lmtime;

27 };

28

29 int aflg, dflg, lflg, sflg, tflg, uflg, lflg, fflg, gflg, cflg;

30 int rflg = 1;

31 long year; /* Глобальные переменные: инициализируются 0 */

32 int flags;

33 int lastuid = -1;

34 char tbuf[16];

35 long tblocks;

36 int statreq;

37 struct lbuf *flist[NFILES];

38 struct lbuf **lastp = flist;

39 struct lbuf **firstp = flist;

40 char *dotp = ".";

41

42 char *makename(); /* char *makename(char *dir, char *file); */

43 struct lbuf *gstat(); /* struct lbuf *gstat(char *file, int argfl); */

44 char *ctime(); /* char *ctime(time_t *t); */

45 long nblock(); /* long nblock(long size); */

46

47 #define ISARG 0100000

Программа начинается с включения файлов (строки 5–8) и объявлений переменных. struct lbuf (строки 14–27) инкапсулирует части struct stat, которые интересны ls. Позже мы увидим, как эта структура заполняется.

Переменные aflg, dflg и т.д. (строки 29 и 30) все указывают на наличие соответствующей опции. Такой стиль именования переменных типичен для кода V7. Переменные flist, lastp и firstp (строки 37–39) представляют файлы, о которых ls выводит сведения. Обратите внимание, что flist является массивом фиксированного размера, которая позволяет обрабатывать не более 1024 файлов. Вскоре мы увидим, как используются все эти переменные.

После объявлений переменных идут объявления функций (строки 42–45), а затем определение ISARG, которая различает файл, указанный в командной строке, от файла, найденного при чтении каталога.

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

50 char *argv[];

51 {

52  int i;

53  register struct lbuf *ep, **ep1; /* Объявления переменных и функций */

54  register struct lbuf **slastp;

55  struct lbuf **epp;

56  struct lbuf lb;

57  char *t;

58  int compar();

59

60  setbuf(stdout, stdbuf);

61  time(&lb.lmtime); /* Получить текущее время */

62  year = lb.lmtime - 6L*30L*24L*60L*60L; /* 6 месяцев назад */

Функция main() начинается с объявления переменных и функций (строки 52–58), устанавливая буфер для стандартного вывода, получая время дня (строки 60–61) и вычисляя значение секунд с начала Эпохи для примерно шести месяцев (строка 62). Обратите внимание, что у всех констант есть суффикс L, указывающий на использование арифметики long.

63  if (--argc > 0 && *argv[1] == '-') {

64   argv++;

65   while (*++*argv) switch(**argv) { /* Разбор опций */

66

67   case 'a': /* Все элементы каталога */

68    aflg++;

69    continue;

70

71   case 's': /* Размер в блоках */

72    sflg++;

73    statreq++;

74    continue;

75

76   case 'd': /* Сведения о каталоге, не содержание */

77    dflg++;

78    continue;

79

80   case 'g': /* Имя группы вместо имени владельца */

81    gflg++;

82    continue;

83

84   case 'l': /* Расширенный листинг */

85    lflg++;

86    statreq++;

87    continue;

88

89   case 'r': /* Обратный порядок сортировки */

90    rflg = -1;

91    continue;

92

93   case 't': /* Сортировка по времени, не по имени */

94    tflg++;

95    statreq++;

96    continue;

97

98   case 'u': /* Время доступа, а не изменения */

99    uflg++;

100   continue;

101

102  case 'c': /* Время изменения индекса, а не файла */

103   cflg++;

104   continue;

105

106  case 'i': /* Включить номер индекса */

107   iflg++;

108   continue;

109

110  case 'f': /* Форсировать чтение каждого arg как каталога */

111   fflg++;

112   continue;

113

114   default: /* Незнакомые буквы опций игнорировать */

115    continue;

116  }

117  argc--;

118 }

Строки 63–118 разбирают опции командной строки. Обратите внимание на ручной разбор кода: getopt() еще не была придумана. Переменная statreq устанавливается в true, когда опция требует использования системного вызова stat().

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

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

119 if (fflg) { /* -f аннулирует -l, -s, -t, добавляя -a */

120  aflg++;

121  lflg = 0;

122  sflg = 0;

123  tflg = 0;

124  statreq = 0;

125 }

126 if (lflg) { /* Открыть файл паролей или групп */

127  t = "/etc/passwd";

128  if (gflg)

129   t = "/etc/group";

130  pwdf = fopen(t, "r");

131 }

132 if (argc==0) { /* Если нет аргументов, использовать текущий */

133  argc++;

134  argv = &dotp - 1;

135 }

Строки 119–125 обрабатывают опцию -f, выключая -l, -s, -t и statreq. Строки 126–131 обрабатывают -l, устанавливая для файла чтение сведений о владельце или группе. Помните, что V7 показывает лишь одно из этих сведений, но не оба.

Если аргументов больше не осталось, строки 132–135 устанавливают argv таким образом, что он указывает на строку, представляющую текущий каталог. Назначение 'argr = &dotp - 1' действительно, хотя и необычно. '- 1' компенсирует '++argv' в строке 137. Это позволяет избежать в главной части программы специального случая для 'argc == 1'.

136  for (i=0; i < argc; i++) { /* Получить сведения о каждом файле */

137   if ((ер = gstat(*++argv, 1))==NULL)

138    continue;

139   ep->ln.namep = *argv;

140   ep->lflags |= ISARG;

141  }

142  qsort(firstp, lastp - firstp, sizeof *lastp, compar);

143  slastp = lastp;

144  for (epp=firstp; epp<slastp; epp++) { /* Глав. код, см. текст */

145   ер = *epp;

146   if (ep->ltype=='d' && dflg==0 || fflg) {

147    if (argc>1)

148     printf("\n%s:\n", ep->ln.namep);

149    lastp = slastp;

150    readdir(ep->ln.namep);

151    if (fflg==0)

152     qsort(slastp, lastp - slastp, sizeof *lastp, compar);

153    if (lflg || sflg)

154     printf("total %D\n", tblocks);

155    for (ep1=slastp; ep1<lastp; ep1++)

156     pentry(*ep1);

157   } else

158   pentry(ep);

159  }

160  exit(0);

161 } /* Конец main() */

Строки 136–141 перебирают аргументы, собирая сведения о каждом. Второй аргумент gstat() булевый: true, если имя является аргументом командной строки, в противном случае false. Строка 140 добавляет флаг ISARG к полю lflags для каждого аргумента командной строки.

Функция gstat() добавляет каждую новую struct lbuf к глобальному массиву flist (строка 137). Она также обновляет глобальный указатель lastp, чтобы он указывал в этом массиве на текущий последний элемент.

Строки 142–143 сортируют массив, используя qsort(), и сохраняют текущее значение lastp в slastp. Строки 144–159 перебирают в цикле каждый элемент массива, выводя соответствующим образом сведения о файле или каталоге.

Код для каталогов заслуживает дальнейшего объяснения:

if (ep->ltype=='d' && dflg==0 || fflg) ...

Строка 146. Если файл является каталогом и -d не предусмотрено или было установлено -f, ls должна прочесть каталог вместо того, чтобы выводить сведения о самом каталоге.

if (argc>1) printf ("\n%s:\n", ep->ln.namep)

Строки 147–148. Выводят имя каталога и двоеточие, если в командной строке было указано несколько файлов.

lastp = slastp;

readdir(ep->ln.namep)

Строки 149–150. Восстанавливают lastp из slastp. Массив flist действует как двухуровневый стек имен файлов. Аргументы командной строки хранятся с firstp до slastp - 1. Когда readdir() читает каталог, она помещает структуры struct lbuf для содержимого каталога в стек, начиная с slastp и до lastp. Это показано на рис. 7.1.

Рис. 7.1. Массив flist как двухуровневый стек

if (fflg==0) qsort(slastp, lastp - slastp, sizeof *lastp, compar)

Строки 151–152. Сортируют элементы подкаталога, если не действует -f.

if (lflg || sflg) printf("total %D\n", tblocks)

Строки 153–154. Выводят для -l или -s общее число блоков, используемых файлами в каталоге. Эта сумма хранится в переменной tblocks, которая сбрасывается для каждого каталога. На современных системах форматирующая строка %D для printf() эквивалентна %ld; она означает «вывести длинное целое». (В V7 есть также %ld, см. строку 192.)

for (ep1=slastp; ep1<lastp; ep1++) pentry(*ep1)

Строки 155–156. Выводит сведения о каждом файле в подкаталоге. Обратите внимание, что V7 ls спускается лишь на один уровень в дереве каталогов. У нее отсутствует современная «рекурсивная» опция -R.

163 pentry(ap) /* void pentry(struct lbuf *ap) */

164 struct lbuf *ap;

165 {

166  struct { char dminor, dmajor;}; /* He использующийся исторический артефакт из V6 ls */

167  register t;

168  register struct lbuf *p;

169  register char *cp;

170

171  p = ap;

172  if (p->lnum == -1)

173   return;

174  if (iflg)

175   printf("%5u ", p->lnum); /* Номер индекса */

176  if (sflg)

177   printf("%4D nblock(p->lsize)); /* Размер в блоках */

Процедура pentry() выводит сведения о файле. Строки 172–173 проверяют, установлен ли -1 в поле lnum, и если так, функция возвращается. Когда верно 'p->lnum == -1', структура struct lbuf недействительна. В противном случае это поле содержит номер индекса файла.

Строки 174–175 выводят номер индекса, если действует -i. Строки 176–177 выводят общее число блоков, если действует -s. (Как мы увидим ниже, это число может быть неточным.)

178  if (lflg) { /* Расширенный листинг: */

179   putchar(p->ltype); /* - Тип файла */

180   pmode(p->lflags); /* - Права доступа */

181   printf("%2d ", p->lnl); /* - Число ссылок */

182   t = p->luid;

183   if (gflg)

184    t = p->lgid;

185   if (getname(t, tbuf)==0)

186    printf("%-6.6s", tbuf); /* - Владелец или группа */

187   else

188    printf("%-6d", t);

189   if (p->ltype=='b' || p->ltype=='c') /* - Устройство: старший и младший номера */

190    printf("%3d,%3d", major((int)p->lsize), minor((int)p->lsize));

191   else

192    printf("%71d", p->lsize); /* - Размер в байтах */

193   cp = ctime(&p->lmtime);

194   if (p->lmtime < year) /* - Время изменения */

195    printf(" %-7.7s %-4.4s ", cp+4, cp+20); else

196    printf(" %-12.12s ", cp+4);

197  }

198  if (p->lflags & ISARG) /* - Имя файла */

199   printf("%s\n", p->ln.namep);

200  else

201   printf("%.14s\n", p->ln.lname);

202 }

Строки 178–197 обрабатывают опцию -l. Строки 179–181 выводят тип файла, права доступа и число ссылок. Строки 182–184 устанавливают t на ID владельца или группы, в зависимости от опции -g. Строки 185–188 получают соответствующее имя и выводят его, если оно доступно. В противном случае программа выводит числовое значение.

Строки 189–192 проверяют, является ли файл блочным или символьным устройством. Если да, они выводят старшее и младшее номера устройств, извлеченные с помощью макросов major() и minor(). В противном случае они выводят размер файла.

Строки 193–196 выводят соответствующее время. Если оно старше шести месяцев, код выводит месяц, день и год. В противном случае, выводятся месяц, день и время (формат результата с time() см. раздел 6.1.3.1 «Простое форматирование времени: asctime() и ctime()»).

Наконец, строки 198–201 выводят имя файла. Мы знаем, что для аргумента командной строки это завершающаяся нулем строка, и может быть использована %s. Для файла, прочитанного из каталога, оно может не завершаться нулем, поэтому должна использоваться явно указанная точность, %.14s.

204 getname(uid, buf) /* int getname(int uid, char buf[]) */

205 int uid;

206 char buf[];

207 {

208  int j, c, n, i;

209

210  if (uid==lastuid) /* Простое кэширование, см. текст */

211   return(0);

212  if (pwdf == NULL) /* Проверка безопасности */

213   return(-1);

214  rewind(pwdf); /* Начать с начала файла */

215  lastuid = -1;

216  do {

217   i = 0; /* Индекс в массиве buf */

218   j = 0; /* Число полей в строке */

219   n = 0; /* Преобразование числового значения */

220   while ((c=fgetc(pwdf)) != '\n') { /* Прочесть строки */

221    if (c==EOF)

222     return(-1);

223    if (c==':') { /* Число полей*/

224     j++;

225     c = '0';

226    }

227    if (j==0) /* первое поле - имя */

228     buf[i++] = c;

229    if (j==2) /* Третье поле - числовой ID */

230     n = n*10 + c - '0';

231   }

232  } while (n != uid); /* Продолжать до обнаружения ID */

233  buf[i++] = '\0';

234  lastuid = aid;

235  return(0);

236 }

Функция getname() преобразует ID владельца или группы в соответствующее имя. Она реализует простую схему кэширования; если переданное uid то же самое, которое находится в глобальной переменной lastuid, функция возвращает 0 (все нормально), буфер уже содержит имя (строки 210–211). lastuid инициализируется в -1 (строка 33), поэтому этот тест не проходит, когда getname() вызывается первый раз.

pwdf уже открыт либо в /etc/passwd, либо в /etc/group (см. строки 126–130). Код здесь проверяет, что открытие было успешным, и если нет, возвращает -1 (строки 212–213).

Удивительно, ls не использует getpwuid() или getgrgid(). Вместо этого она использует преимущество того факта, что формат /etc/passwd и /etc/group идентичен для трех первых полей (имя, пароль, числовой ID) и что оба используют в качестве разделителя двоеточие.

Строки 216–232 реализуют линейный поиск по файлу. j содержит число обнаруженных до сих пор двоеточий: 0 для имени и 2 для ID. Таким образом, при сканировании строки она заполняет как имя, так и ID.

Строки 233–235 завершают буфер name, устанавливают в глобальной lastuid последний найденный ID и возвращают 0 для обозначения успеха.

238 long /* long nblock(long size) */

239 nblock(size)

240 long size;

241 {

242  return ((size+511) >>9);

243 }

Функция nblock() сообщает, сколько дисковых блоков использует файл. Это вычисление основано на размере файла, возвращенном stat(). Размер блока V7 равен 512 байтам — размер физического сектора диска.

Вычисление в строке 242 выглядит несколько устрашающим. '>>9' является сдвигом вправо на девять битов. Это осуществляет деление на 512 для получения числа блоков. (На раннем аппаратном обеспечении сдвиг вправо выполнялся гораздо быстрее деления.) Пока все хорошо. Теперь, файл даже размером в один байт все равно занимает целый дисковый блок. Однако, '1 / 512' дает ноль (целое деление срезает), что неверно. Это объясняет 'size+511'. Добавляя 511, этот код гарантирует, что сумма дает правильное число блоков при делении на 512.

Это вычисление, однако, лишь приблизительное. У очень больших файлов есть также дополнительные блоки. Несмотря на заявление в справочной странице V7 ls(1), данное вычисление не принимает в расчет дополнительные блоки.

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

По этим причинам в struct stat 4 2 BSD были добавлены члены st_blocks, которые затем были приняты для System V и POSIX.

245 int m1[] = { 1, S_IREAD>>0, 'r', '-' };

246 int m2[] = { 1, S_IWRITE>>0, 'w', '-' };

247 int m3[] = { 2, S_ISUID, 's', S_IEXEC>>0, 'x', '-' };

248 int m4[] = { 1, S_IREAD>>3, 'r', '-' };

249 int m5[] = { 1, S_IWRITE>>3, 'w', '-' };

250 int m6[] = { 2, S_ISGID, 's', S_IEXEC>>3, 'x', '-' };

251 int m7[] = { 1, S_IREAD>>6, 'r', '-' };

252 int m8[] = { 1, S_IWRITE>>6, 'w', '-' };

253 int m9[] = { 2, S_ISVTX, ' t', S_IEXEC>>6, 'x', '-' };

254

255 int *m[] = { m1, m2, m3, m4, m5, m6, m7, m8, m9 };

256

257 pmode(aflag) /* void pmode(int aflag) */

258 {

259  register int **mp;

260

261  flags = aflag;

262  for (mp = &m[0]; mp < &m[sizeof(m)/sizeof(m[0])];)

263   select(*mp++);

264 }

265

266 select(pairp) /* void select(register int *pairp) */

267 register int *pairp;

268 {

269  register int n;

270

271  n = *pairp++;

272  while (--n>=0 && (flags&*pairp++)==0)

273   pairp++;

274  putchar(*pairp);

275 }

Строки 245–275 выдают права доступа к файлу. Код компактен и довольно элегантен, он требует тщательного изучения.

• Строки 245–253: массивы с m1 по m9 кодируют биты прав доступа для проверки вместе с соответствующими буквами для вывода. На каждую выводимую букву режима файла имеется один массив. Первый элемент каждого массива является числом пар (право доступа, буква), закодированных в данном конкретном массиве. Последний элемент является буквой, которая должна быть выведена в случае, если не найден ни один из битов прав доступа.

Обратите также внимание, что права доступа обозначены как 'I_READ>>0', 'I_READ>>3', 'I_READ>>6' и т.д. Отдельные константы для каждого бита (S_IRUSR, S_IRGRP и т.п.) не были еще придуманы. (См. табл. 4.5 в разделе 4 6.1 «Указание начальных прав доступа к файлу».)

• Строка 255: массив m указывает на каждый из массивов с m1 по m9.

• Строки 257–264: функция pmode() сначала устанавливает глобальную переменную flags равной переданному параметру aflag. Затем она просматривает в цикле массив m, передавая каждый элемент функции select(). Переданный элемент представляет один из массивов с m1 по m9.

• Строки 266–275: функция select() понимает структуру каждого из массивов с m1 по m9. n является числом пар в массиве (первый элемент); его устанавливает строка 271. Строки 272–273 ищут биты прав доступа, проверяя установленную ранее в строке 261 глобальную переменную flags.

Обратите внимание на использование оператора ++ как в проверке цикла, так и в теле цикла. Результатом является пропуск пары в массиве, если в flags не обнаружен бит доступа в первом элементе пары.

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

Последним стоящим внимания моментом является то, что на С символьные константы (такие как 'x') имеют тип int, а не char[75]. Поэтому проблем с помещением этих констант в массив целых нет; все работает правильно.

277 char* /* char *makename(char *dir, char *file) */

278 makename(dir, file)

279 char *dir, *file;

280 {

281  static char dfile[100];

282  register char *dp, *fp;

283  register int i;

284

285  dp = dfile;

286  fp = dir;

287  while (*fp)

288   *dp++ = *fp++;

289  *dp++ = '/';

290  fp = file;

291  for (i=0; i<DIRSIZ; i++)

292   *dp++ = * fp++;

293  *dp = 0;

294  return(dfile);

295 }

Строки 277–295 определяют функцию makename(). Ее работа заключается в соединении имени каталога с именем файла, разделенным символом косой черты, с образованием строки. Она осуществляет это в static буфере dfile. Обратите внимание, что dfile всего лишь 100 символов длиной и что проверка ошибок не выполняется.

Сам код прост, он копирует по одному символу за раз. makename() используется функцией readdir().

297 readdir(dir) /* void readdir(char *dir) */

298 char *dir;

299 {

300  static struct direct dentry;

301  register int j;

302  register struct lbuf *ep;

303

304  if ((dirf = fopen(dir, "r")) == NULL) {

305   printf("%s unreadable\n", dir);

306   return;

307  }

308  tblocks = 0;

309  for(;;) {

310   if (fread((char*)&dentry, sizeof(dentry), 1, dirf) != 1)

311    break;

312   if (dentry.d_ino==0

313    || aflg==0 && dentry.d_name[0]=='.' && (dentry.d_name[1]=='\0'

314    || dentry.d_name[1]=='.' && dentry, d_name[2]=='\0'))

315    continue;

316   ep = gstat(makename(dir, dentry.d_name), 0);

317   if (ep==NULL)

318    continue;

319   if (ep->lnum != -1)

320    ep->lnum = dentry.d_ino;

321   for (j =0; j<DIRSIZ; j++)

322    ep->ln.lname[j] = dentry.d_name[j];

323  }

324  fclose(dirf);

325 }

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

Строки 304–307 открывают каталог для чтения, завершая функцию, если fopen() возвращает ошибку. Строка 308 инициализирует глобальную переменную tblocks нулем. Ранее (строки 153–154) это использовалось для вывода общего числа блоков, использованных файлами в каталоге.

Строки 309–323 являются циклом, который читает элементы каталога и добавляет их к массиву flist. Строки 310–311 читают один элемент, выходя из цикла в конце файла.

Строки 312–315 пропускают неинтересные элементы. Если номер индекса равен нулю, этот слот не используется. В противном случае, если не был указан -а и имя файла является '.' или '..', оно пропускается.

Строки 316–318 вызывают gstat() с полным именем файла и вторым аргументом, равным false, указывающим, что он не из командной строки. gstat() обновляет глобальный указатель lastp и массив flist. Возвращаемое значение NULL обозначает какую-нибудь разновидность ошибки.

Строки 319–322 сохраняют номер индекса и имя в struct lbuf. Если ep->lnum возвращается из gstat() установленным в -1, это означает, что операция stat() с файлом завершилась неудачей. Наконец, строка 324 закрывает каталог.

Следующая функция, gstat() (строки 327–398), является центральной функцией для получения и сохранения сведений о файле.

327 struct lbuf * /* struct lbuf *gstat(char *file, int argfl) */

328 gstat(file, argfl)

329 char *file;

330 {

331  extern char *malloc();

332  struct stat statb;

333  register struct lbuf *rep;

334  static int nomocore;

335

336  if (nomocore) /* Ранее была нехватка памяти */

337   return(NULL);

338  rep = (struct lbuf*)malloc(sizeof(struct lbuf));

339  if (rep==NULL) {

340   fprintf(stderr, "ls: out of memory\n");

341   nomocore = 1;

342   return(NULL);

343  }

344  if (lastp >= &flist[NFILES]) { /* Проверить, не дано ли слишком много файлов */

345   static int msg;

346   lastp--;

347   if (msg==0) {

348    fprintf(stderr, "ls: too many files\n");

349    msg++;

350   }

351  }

352  *lastp++ = rep; /* Заполнить сведения */

353  rep->lflags = 0;

354  rep->lnum = 0;

355  rep->ltype = '-'; /* Тип файла по умолчанию */

Статическая переменная nomocore [важно] указывает, что malloc() при предыдущем вызове завершилась неудачей. Поскольку она статическая, она автоматически инициализируется 0 (т.е. false). Если на входе она равна true, gstat() просто возвращает NULL. В противном случае, если malloc() завершается неудачей, ls выводит сообщение об ошибке, устанавливает в nomocore true и возвращает NULL (строки 334–343).

Строки 344–351 гарантируют, что в массиве flist все еще остается место. Если нет, ls выдает сообщение (но лишь однажды; заметьте использование статической переменной msg), а затем повторно использует последний слот flist.

Строка 352 заставляет слот lastp указывать на новую struct lbuf (rep). Это также обновляет lastp, который используется для сортировки в main() (строки 142 и 152). Строки 353–355 устанавливают значения по умолчанию для полей флагов, номеров индексов и типов в struct lbuf.

356  if (argfl || statreq) {

357   if (stat(file, &statb)<0) { /* stat() завершилась неудачей */

358    printf("%s not found\n", file);

359    statb.st_ino = -1;

360    statb.st_size = 0;

361    statb.st_mode = 0;

362    if (argfl) {

363     lastp--;

364     return(0);

365    }

366   }

367   rep->lnum = statb.st_ino; /* stat() OK, копировать сведения */

368   rep->lsize = statb.st_size;

369   switch(statb.st_mode & S_IFMT) {

370

371   case S_IFDIR:

372    rep->ltype = 'd';

373    break;

374

375   case S_IFBLK:

376    rep->ltype = 'b';

377    rep->lsize = statb.st_rdev;

378    break;

379

380   case S_IFCHR:

381    rep->ltype = 'c';

382    rep->lsize = statb.st_rdfev;

383    break;

384   }

385   rep->lflags = statb.st_mode & ~S_IFMT;

386   rep->luid = statb.st_uid;

387   rep->lgid = statb.st_gid;

388   rep->lnl = statb.st_nlink;

389   if (uflg)

390    rep->lmtime = statb.st_atime;

391   else if (cflg)

392    rep->lmtime = statb.st_ctime;

393   else

394    rep->lmtime = statb.st_mtime;

395   tblocks += nblock(statb.st_size);

396  }

397  return(rep);

398 }

Строки 356–396 обрабатывают вызов stat(). Если это аргумент командной строки или если statreq установлен в true благодаря опции, код заполняет struct lbuf следующим образом:

• Строки 357–366: вызывают stat(), при ее неудаче выводится сообщение об ошибке с установкой соответствующих значений, затем возвращается NULL (выраженный в виде 0).

• Строки 367–368: устанавливают в struct stat поля номера индекса и размера, если вызов stat() был успешным.

• Строки 369–384: обрабатывают особые случаи каталогов, блочных и символьных устройств. Во всех случаях код обновляет поле ltype. Для устройств значение lsize замещается значением st_rdev.

• Строки 385–388. заполняются поля lflags, luid, lgid и lnl из соответствующих полей в struct stat. Строка 385 удаляет биты типа файла, оставляя 12 битов прав доступа (на чтение/запись/исполнение для владельца/группы/остальных, а также setuid, setgid и save-text).

• Строки 389–394: основываясь на опциях командной строки, используют одно из трех полей времени в struct stat для поля lmtime в struct lbuf.

• Строка 395: обновляет глобальную переменную tblocks числом блоков в файле.

400 compar(pp1, pp2) /* int compar(struct lbuf **pp1, */

401 struct lbuf **pp1, **pp2; /* struct lbuf **pp2) */

402 {

403  register struct lbuf *p1, *p2;

404

405  p1 = *pp1;

406  p2 = *pp2;

407  if (dflg==0) {

408   if (p1->lflags&ISARG && p1->ltype=='d') {

409    if (!(p2->lflags&ISARG && p2->ltype=='d'))

410     return(1);

411   } else {

412    if (p2->lflags&ISARG && p2->ltype=='d')

413     return(-1);

414   }

415  }

416  if (tflg) {

417   if(p2->lmtime == p1->lmtime)

418    return(0);

419   if (p2->lmtime > p1->lmtime)

420    return(rflg);

421   return(-rflg);

422  }

423  return(rflg * strcmp(p1->lflags&ISARG ? p1->ln.namep : p1->ln.lname,

424   p2->lflags&ISARG ? p2->ln.namep : p2->ln.lname));

425 }

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

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

Наконец, переменная rflg помогает реализовать опцию -r, которая меняет порядок сортировки. Она инициализируется 1 (строка 30). Если -r используется, rflg устанавливается в -1 (строки 89–91).

Следующий псевдокод описывает логику compar(); номера строк на левой границе соответствуют номерам строк ls.c:

407 if ls должна прочесть каталоги # dflg == 0

408  if p1 аргумент командной строки и p1 каталог

409   if p2 не аргумент командной строки и не каталог

410    return 1 # первый идет после второго

      else

       перейти на тест времени

411  else

      # p1 не каталог командной строки

412   if p2 аргумент командной строки и каталог

413    return -1 # первый идет перед вторым

      else

       перейти на тест времени

416 if сортировка основана на времени # tflg равно true

     # сравнить времена:

417  if время p2 равно времени p1

418   return 0

419  if время p2 > времени p1

420   return значение rflg (положительное или отрицательное)

     # время p2 < времени p1

421  return противоположное rflg значение (положительное или отрицательное)

423 Умножить rflg на результат strcmp()

424 для двух имен и вернуть результат

Аргументы strcmp() в строках 423–424 выглядят сбивающими с толку. В зависимости от того, было ли имя файла указано в командной строке или было прочитано из каталога, должны использоваться различные члены объединения ln в struct lbuf.

7.3. Резюме

• V7 ls является сравнительно небольшой программой, хотя она затрагивает многие фундаментальные аспекты программирования Unix — файловый ввод-вывод, вспомогательные данные файлов, содержание каталогов, пользователи и группы, значения времени и даты, сортировку и динамическое управление памятью.

• Наиболее примечательным внешним различием между V7 ls и современной ls является трактовка опций и -l. У версии V7 значительно меньше опций, чем у современных версий; заметным недостатком является отсутствие рекурсивной опции -R.

• Управление flist является чистым способом использования ограниченной памяти архитектуры PDP-11, предоставляя в то же время как можно больше сведений, struct lbuf хорошо извлекает нужные сведения из struct stat; это значительно упрощает код. Код для вывода девяти битов доступа компактен и элегантен.

• Некоторые части ls используют удивительно маленькие лимиты, такие, как верхняя граница числа файлов в 1024 или размер буфера в makename() в 100.

Упражнения

1. Рассмотрите функцию getname(). Что случится, если запрошенный ID равен 256, а в /etc/passwd есть следующие две строки, в этом порядке:

joe:xyzzy:2160:10:Joe User:/usr/joe:/bin/sh

jane:zzyxx:216:12:Jane User:/usr/jane:/bin/sh

2. Рассмотрите функцию makename(). Может ли она использовать sprintf() для составления имени? Почему может или почему нет?

3. Являются ли строки 319–320 в readdir() действительно необходимыми?

4. Возьмите программу stat, которую вы написали в качестве упражнения в «Упражнениях» к главе 6. Добавьте функцию nblock() из V7 ls и выведите результаты вместе с полем st_blocks из struct stat. Добавьте видимый маркер, когда они различны.

5. Как бы вы оценили V7 ls по ее использованию malloc()? (Подсказка: как часто вызывается free()? Где ее следовало бы вызвать?)

6. Как вы оценили бы ясность кода V7 ls? (Подсказка: сколько там комментариев?)

7. Очертите шаги, которые нужно было бы сделать, чтобы адаптировать V7 ls для современных систем.

Глава 8 Файловые системы и обходы каталогов

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

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

8.1. Монтирование и демонтирование файловых систем

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

8.1.1. Обзор основ

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

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

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

Эти две задачи выполняются программами mount и umount [так], названными по соответствующим системным вызовам. У системного вызова mount() каждой системы Unix свой, отличный интерфейс. Поскольку монтирование и демонтирование считаются проблемой реализации, POSIX намеренно не стандартизует эти системные вызовы

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

Ядро поддерживает уникальный номер, известный как номер устройства, который идентифицирует каждый смонтированный раздел. По этой причине именно пара (устройство, индекс) вместе уникально идентифицируют файл; когда структуры 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 продолжали поддерживать один тип файловой системы. Для переключения компьютера от одной файловой системы на другую[77] приходилось сначала резервировать каждую файловую систему на среду архивирования (9-дорожечную ленту), обновлять систему, а затем восстанавливать данные.

В середине 1980-х Sun Microsystems разработала архитектуру ядра, которая сделала возможным использование нескольких архитектур файловой системы в одно и то же время. Этот проект был реализован в их операционной системе SunOS, сначала для поддержки сетевой файловой системы Sun (Network File System — NFS). Однако, как следствие, стало возможным также поддерживать несколько архитектур на диске. System V Release 3 использовала сходную архитектуру для поддержки удаленной файловой системы (Remote File System — RFS), но она продолжала поддерживать лишь одну архитектуру на диске.[78] (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)

Имя Режим Описание
afs RW Andrew File System (файловая система Andrew)
adfs RW Acorn Advanced Disc Filing System (расширенная дисковая файловая система Acorn)
affs RO, RW Amiga Fast File system (быстрая файловая система Amiga) Режим «только для чтения» в противоположность режиму «для записи и чтения» зависит от версии файловой системы
autofs RW Файловая система для взаимодействия с демоном автоматического монтирования
befs RO Файловая система BeOS. Помечена как программное обеспечение альфа.
bfs RW SCO UnixWare Boot File system (загрузочная файловая система SCO Unix).
binfmt-misc RW Специальная файловая система для запуска интерпретаторов компилированных файлов (например, файлов Java)
efs RW Файловая система, разработанная для варианта Unix SGI, названного Irix
coda RW Экспериментальная распределенная файловая система, разработанная в CMU[79]
cramfs RO Небольшая файловая система для хранения файлов в постоянной памяти (ROM).
devfs RW Способ динамического предоставления файлов для /dev (устарело).
devpts RW Специальная файловая система для псевдотерминалов.
ext2 RW Вторая расширенная файловая система. Файловая система по умолчанию для GNU/Linux, хотя некоторые дистрибутивы используют теперь ext3.
ext3 RW Файловая система ext2 с журналированием
hfs RW Hierarchical File System (иерархическая файловая система) Apple Mac OS.
hpfs RW High Performance File System (высокопроизводительная файловая система) OS/2.
intermezzo RW Экспериментальная распределенная файловая система для работы в отсоединенном от сети состоянии. См веб-сайт InterMezzo (http://www.inter-mezzo.org)
jffs RW Journalled Flash File system (журналируемая файловая система с групповой записью/считыванием, для встроенных систем)
jffs2 RW Journalled Flash File system 2 (тоже для встроенных систем)
iso9660 RO Файловая система ISO 9660 для CD-ROM. Поддерживаются также расширения Rock Ridge, заставляющие выглядеть использующие их CD-ROM как нормальная файловая система (но только для чтения).
jfs RW Journalled File System (журналируемая файловая система) IBM для Linux.
ncp RW Протокол Novell NCP для NetWare; клиент удаленной файловой системы.
ntfs RO Поддержка файловой системы NTFS Windows
openpromfs RO Файловая система /proc для PROM на системах SPARC
proc RW Доступ к информации о процессах и ядре
qnx4 RW Файловая система QNX4 (небольшой операционной системы реального времени)
ramfs RW Файловая система для создания RAM-дисков.
reiserfs RW Развитая журналируемая файловая система
romfs RO Файловая система для создания простых RAM-дисков только для чтения.
smbfs RW Поддержка клиента для файловых систем SMB (разделяемых файлов Windows)
sysv RW Файловые системы System V Release 2, Xenix, Minix и Coherent. coherent, minix и xenix являются псевдонимами
tmpfs RW Файловая система электронного диска, поддерживающая динамический рост.
udf RO Формат файловой системы UDF, используемый в DVD-ROM
ufs RO, RW Быстрая файловая система BSD, на современных системах с доступом для чтения и записи.
umsdos RW Расширение vfat, заставляющее выглядеть ее подобно файловой системе Unix
usbfs RW Специальная файловая система для работы с устройствами USB. Первоначальным именем было usbdevfs, это имя до сих пор появляется, например, в выводе mount
vfat RW Все варианты файловых систем FAT MS-DOS/Windows Компонентами являются msdos и fat
vxfs RW Журналируемая файловая система Veritas VxFS.
xfs RW Высокопроизводительная журналирующая файловая система, разработанная SGI для Linux. См веб-сайт XFS (http://oss.sgi.com/projects/xfs/)

Не все из этих файловых систем поддерживаются командой 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 в конечном счете стала доминирующей файловой системой.[80]

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 работает */

8.2. Файлы для администрирования файловой системы

Файл /etc/fstab[81] перечисляет файловые системы, которые могут быть смонтированы. Большинство из них монтируются автоматически, когда система загружается. Формат следующий:

устройство точка-монтирования тип-фс опции 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 при работе с этим разделом.