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

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

уровня пользователя

), но и к самой операционной системе (коду

уровня ядра

). Поэтому не только «Маленький — значит красивый» в эстетическом смысле, но «Маленький — значит красивый», потому что не было другого выбора!

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

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

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

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

jane

является начальником пользователя

fred

, и

jane

не хочет, чтобы

fred

прочел последние результаты аттестации.

В целях создания прав доступа пользователи подразделяются на три различные категории:

владелец

файла;

группа

пользователей, связанная с данным файлом (вскоре будет пояснено); и

остальные пользователи

. Для каждой из этих категорий

каждый

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

ls -l

':

$ ls -l progex.texi

Раз у вас есть файл, нужно где-то его хранить. В этом назначение

каталога

(известного в системах Windows или Apple Macintosh под названием «папка»). Каталог является особой разновидностью файла, связывающего имена файлов с метаданными, известными как

узлы

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

Имена файлов могут содержать любой 8-битный байт, за исключением символа '

/

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

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

о

файле, а не данные самого файла, отсюда термин

метаданные

.

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

удалять

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

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

объектного файла

, которое определяет, как эти данные располагаются внутри файла на диске.

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

ld

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

root

).

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

Ядро распознает, что исполняемый файл содержит двоичный объектный код, проверяя первые несколько байтов файла на предмет совпадения со специальными

магическими числами

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

Помимо двоичных исполняемых файлов, ядро поддерживает также исполняемые

Одним из самых замечательных новшеств 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

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

Процесс является работающей программой.

[15]

Процесс имеет следующие атрибуты:

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

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

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

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

Без сомнения, вам приходилось использовать конструкцию ('

|

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

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

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

Что делает программу 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

, которые относятся к проектированию и реализации программ.

Глава 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.

Глава 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, посвящена механике разбора аргументов и опций.

Наиболее привлекательной частью

GNU Coding Standards

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

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

gawk

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

gawk

от этой части стандартов кодирования.

Тем не менее, хотя нам и не нравится стиль FSF

[21]

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

GNU Coding Standards

дает такой же совет. (Иногда невозможно обнаружить последовательный стиль кода, в этом случае программа, возможно, испорчена использованием

indent

от GNU или

cb

от Unix.)

Что мы сочли важным в главе о написании кода на С, это то, что эти советы хороши для

любого

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

Теперь мы рассмотрим раздел, озаглавленный «

Написание надежных программ

», в главе 4 «

Поведение программ для всех программ

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

Это правило, возможно, единственное наиболее важное в проектировании программного обеспечения GNU —

никаких произвольных ограничений

. Все инструменты GNU должны быть способны обрабатывать произвольные объемы данных.

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

gawk

, регулярно запускающий программу

awk

для более чем 650 000 файлов (нет, это не опечатка) для сбора статистики,

gawk

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

awk

.

[22]

У слова

аргументы

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

$ ls main.с opts.с process.с

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

[27]

.

Второе определение более неформальное: аргументами являются все слова командной строки,

за исключением

имени команды. По умолчанию, оболочки Unix отделяют аргументы друг от друга

разделителями

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

$ echo here are lots of spaces

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

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

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

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

-W

зарезервирована для специфичных для производителя опций.

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

-

'.

Как мы видели в разделе 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

.

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

argc

и

argv

. Параметр

argc

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

main()

, отличающихся способом объявления

argc

:

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

{                                 {

...                                ...

}                                 }

Возможно, простейшим примером обработки командной строки является программа V7

echo,

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

-n

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

[28]

:

1  #include <stdio.h>

2

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

4  int argc;

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

intro

(1) значительно менее формально, чем в стандарте POSIX.)

Группа поддержки Unix разработала также функцию

getopt()

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

getopt_long()

предоставляет совместимую с

getopt()

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

Функция

getopt()

объявлена следующим образом:

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

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

extern char *optarg;

Стандартная функция

getopt()

прекращает поиск опций, как только встречает аргумент командной строки, который не начинается с GNU

getopt()

отличается: она просматривает в поисках опций всю командную строку. По мере продвижения она переставляет элементы

argv

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

argv[optind]

до

argv[argc-1]

, работает правильно. Во всех случаях специальный аргумент '

--

' завершает сканирование опций.

Вы можете изменить поведение по умолчанию, использовав в

optstring

специальный первый символ следующим образом:

optstring[0] == '+'

GNU

getopt()

ведет себя, как стандартная

getopt()

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

POSIXLY_CORRECT

.

optstring[0] == '-'

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

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

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

getopt_long()

2.3.3.4. GNU

getopt()

или

getopt_long()

в программах пользователей

Окружение

представляет собой набор пар вида '

имя = значение

' для каждой программы. Эти пары называются

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

. Каждое имя состоит от одной до любого числа буквенно-цифровых символов или символов подчеркивания ('

_

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

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

POSIXLY_CORRECT

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

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

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

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

#include <stdlib.h>

char *getenv(const char *name);

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

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

Внешняя переменная

environ

предоставляет доступ таким же способом, как

argv

предоставляет доступ к аргументам командной строки. Вы сами должны объявить переменную. Хотя она и стандартизирована POSIX,

environ

намеренно не объявлена ни в одном стандартном заголовочном файле (Это, кажется, прослеживается из исторической практики.) Вот объявление:

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

Как и в

argv

, завершающим элементом

environ

является

NULL

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

argc

. Следующая простая программа распечатывает все окружение:

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

Чтобы завершить главу, рассмотрим GNU версию команды

env

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

getopt_long()

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

$ env --help

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

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

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

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

new

и

delete

.

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

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

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

malloc()

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

free()

3.2.1.4. Изменение размера:

realloc()

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

strdup()

:

#include <string.h>

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

char *strdup(const char *str) {

Четыре функции, которые мы рассмотрели (

malloc()

,

calloc()

,

realloc()

и

free()

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

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

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

#include <malloc.h> /* Необходим для систем GLIBC 2 */

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

alloca()

; она объявлена следующим образом:

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

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

void *alloca(size_t size);

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

всегда

проверять успешность завершения каждой операции.

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

int result;

result = some_system_call(param1, param2);

if (result < 0) {

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

errno

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

Таблица 4.1

. Значения GLIBC для

errno

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

intro

(2) и

errno

(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));

Все операции Linux по вводу/выводу осуществляются посредством

дескрипторов файлов

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

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

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

ulimit -n

' печатает это значение:

$ ulimit -n

1024

Из С максимальное число открытых файлов возвращается функцией

getdtablesize()

(получить размер таблицы дескрипторов):

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

4.4.2.1. Отображение переменных

FILE*

на дескрипторы файлов

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

Ввод/вывод осуществляется системными вызовами

read()

и

write()

соответственно:

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

#include <sys/stat.h>

#include <fcntl.h>

#include <unistd.h>

Как и было обещано, вот версия cat V7

[47]

. Она начинается с проверки опций,

cat

V7 принимает единственную опцию,

-u

, для осуществления небуферированного вывода.

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

<stdio.h>

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

1  /*

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

3   */

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

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

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

Раздел (partition)

Единица физического хранилища.

Физические разделы

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

логические разделы

.

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

Рис. 5.2

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

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

/usr/include/sys/dir.h

:

#ifndef DIRSIZ

5.1.3.1. Программа GNU link

5.1.3.2. Точка и точка-точка

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

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

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

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

Ранние версии команды mv работали таким способом. Однако, при таком способе переименование файла не является

атомарным

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

[51]

, разрушая операцию переименования и подменяя оригинальный файл другим.

В оригинальных системах 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;

5.3.1.1. Анализ переносимости

5.3.1.2. Элементы каталогов Linux и BSD

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

#include <dirent.h> /* XSI */

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

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

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

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

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

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

ls -l

' они обозначаются в виде первого символа '

-

' поля прав доступа (режима).

Каталоги

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

ls -l

' они обозначаются первым символом

d

поля прав доступа.

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

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

#include <sys/stat.h>

#include <unistd.h>

Ядра Linux 2.6 и более поздние предоставляют в

struct stat

три дополнительных поля. Они предусматривают точность файлового времени до наносекунд:

st_atime_nsec 

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

st_mtime_nsec 

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

st_ctime_nsec 

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

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

struct stat

не

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

utimes()

».)

5.4.4.1. Сведения об устройстве

5.4.4.2. Возвращаясь к V7

cat