Главная » Программирование для UNIX » Что в файле?

0

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

$ file /bin /bin/ed /usr/src/cmd/ed.c  /usr/man/man1/ed.1

/bin:      directory

/bin/ed:            pure  executable

/usr/src/cmd/ed.c:           c program  text

/usr/man/man1/ed.1:        roff, nroff,  or  eqn input  text

$

Здесь  представлены четыре типичных файла, относящиеся к редактору:  каталог, в котором они расположены (/bin), собственно двоичный исполняемый файл (/bin/ed), файл с исходным текстом на С (/usr/src/ cmd/ed.c) и страница руководства (/usr/man/man1/ed.1).

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

Иногда ключи очевидны. Исполняемая программа начинается с «ма гического числа» в двоичном представлении. Команда od без параметров выводит дамп  файла 16-битными порциями или  2-байтовыми словами, позволяя увидеть это волшебное число:1

$ od /bin/ed

0000000 000410 025000 000462 011444 000000 000000  000000 000001

0000020 170011 016600 000002 005060 177776 010600  162706 000004

0000040 016616 000004 005720 010066 000002 005720  001376 020076

$

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

В текстовых файлах ключи могут  встречаться  среди  прочего текста, поэтому file определяет  исходные тексты на  Си  по  наличию таких слов, как #include, а входные данные программ nroff или  troff – по наличию точки в начале строки.

Может возникнуть вопрос, почему система не следит за типами фай лов более  тщательно, чтобы, например, не допустить применения команды sort к файлу /bin/ed. Одна  из  причин – нежелание запрещать некоторые полезные действия. Хотя  команда

$ sort /bin/ed

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

1        В современных реализациях UNIX получили распространение более совер шенные и сложные  форматы двоичных исполняемых файлов, но,  тем  не менее, find для  их  определения следует изложенным здесь  принципам. – Примеч. науч. ред.

пользование. Такие команды, как od, wc, cp, cmp, file и многие другие, работают с файлами независимо от их  содержимого. Но идея бесформатных файлов еще глубже. Если бы, к примеру, входные файлы nroff отличались по формату от исходных текстов на Си,  редактору пришлось  бы вставлять эти  различия при создании файла и обрабатывать их  при  чтении  и  повторном редактировании.  А это  определенно затруднило бы авторам создание примеров на Си в главах с 6 по 8!

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

$ od -c  junk  >temp

$ ed ch2.1

1534

r  temp

168

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

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

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

1        Даг Мак-Илрой (Doug McIlroy) предложил хороший тест для проверки единообразия файловой системы – UNIX  прошла его без проблем. Может ли вывод  программы,  написанной на  Фортране, быть  использован как  вход для компилятора Фортрана? Подавляющее большинство систем испытывают затруднения при прохождении этого теста.

как в большинстве из них  сделаны неявные предположения о максимальной длине текстовой строки (см., например, раздел BUGS страницы руководства sort(1)).

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

Источник: Керниган Б., Пайк Р., UNIX. Программное окружение. – Пер. с англ. – СПб: Символ-Плюс, 2003. – 416 с., ил.

По теме:

  • Комментарии