Программы выбирают данные из файла с помощью системного обращения с именем read (подпрограмма в ядре). При каждом обращении к read читается следующая часть файла, например очередная введенная строка. Подпрограмма read также сообщает число прочитанных байтов файла, поэтому конец файла обнаруживается, когда она сообщает: "прочитано 0 байт". Если какие-либо байты оставались в файле, то подпрограмма read выдала хотя бы часть их. На самом деле, отказ от ввода байта со специальным значением "конец файла" вполне оправдан, поскольку, как отмечалось ранее, смысл содержимого байта зависит от интерпретации файла. Но все файлы имеют конец, и поэтому их следует читать с помощью подпрограммы read, а возврат нуля это зависящий от интерпретации способ представления конца файла без использования специальных символов.
Когда программа читает с вашего терминала, каждая введенная строка передается программе ядром только после ввода символа перевода строки (т.е. нажатия RETURN). Поэтому если вы сделаете ошибки и заметите это до ввода RETURN, можно вернуться и исправить их. Если символ перевода строки введен до того, как вы заметили ошибку, то строка уже прочитана системой и исправить ее нельзя.
Можно посмотреть ввод по строкам на примере команды cat. Эта команда обычно накапливает или буферизует свой выходной поток, чтобы для повышения эффективности писать большими порциями, но флаг -u отключает буферизацию, так что она выдает строку сразу по получении:
$ cat Выдача команды cat с буферизацией
123
456
789
ctl-d
123
456
789
$ cat -u Выдача команды cat без буферизации
123
123
456
456
789
789
ctl-d
$
Команда cat получает каждую строку, когда вы нажимаете клавишу RETURN; без буферизации она выдает данные, как только их получит.
Теперь попробуем сделать нечто другое: введите несколько символов, а затем вместо RETURN наберите на клавиатуре ctl-d:
$ cat -u 123ctl-d123
Команда cat выдает символы мгновенно. Символ ctl-d означает, что нужно немедленно послать символы, введенные с терминала, программе, которая производит ввод с терминала. В отличие от символа перевода строки ctl-d не передается программе. Теперь введите второй раз ctl-d без каких-либо символов:
$ cat -u
123ctl-d123ctl-d$
Интерпретатор отвечает на это выводом приглашения, поскольку команда cat, не получив символов, считает, что файл кончился, и прекращает работу. Символ ctl-d передает все, что вы ввели, программе, производящей ввод с терминала. Если вы ничего не ввели, программа не получит никаких символов, что соответствует концу файла. Именно поэтому ввод ctl-d приводит к выходу из системы интерпретатор не получает больше входной информации. Конечно, символ ctl-d в основном используется как сигнал о конце файла, но он имеет и более общее назначение.
Упражнение 2.1
Что произойдет, если ввести ctl-d редактору ed? Сравните этот случай с вводом команды
$ ed < файл
2.2 Что хранится в файле?
Формат файла зависит от программ, которые используют его. Типы файла весьма разнообразны, возможно, потому, что существует большое разнообразие программ. Но, поскольку типы файла не определяются файловой системой, ядро не может указать вам тип файла оно не знает его. Команда 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 program text
/usr/man/man1/ed.1: roff, nroff, or eqn input text
Здесь показаны четыре типичных файла. Все они связаны с редактором: каталог (/bin), в котором находится редактор, двоичный файл или сама программа, готовая к выполнению (/bin/ed), входной текст, т.е. операторы языка Си, составляющие программу (/usr/src/cmd/ed.с), и страница справочного руководства (/usr/man/man1/ed.1).
При определении типа файла команда file не обращает внимания на имена (хотя могла бы), поскольку соглашения об именах — это всего лишь соглашения и поэтому на них нельзя полагаться полностью. Например, файлы, оканчивающиеся на .с, почти всегда содержат текст программы на языке Си, но ничто не мешает вам создать файл, оканчивающийся на .с, с произвольным содержанием. Команда file читает первые несколько сотен байтов файла и пытается по ним определить тип последнего. (Как мы покажем позднее, файлы специального системного назначения, такие, как каталоги, могут быть идентифицированы путем запроса системы, но эта команда может определить каталог, читая его.)
Иногда установить тип файла нетрудно. Выполняемая программа помечается вначале двоичным "магическим" числом. Команда od, запущенная без всяких флагов, выдает содержимое файла по словам в 16-разрядном или двухбайтовом представлении, и магическое число становится видимым:
$ od /bin/ed
0000000 000410 025000 000462 011444 0000000 000000 000000 000001
0000020 170011 016600 000002 005060 1777776 010600 162706 000004
0000040 016616 000004 005720 010066 0000002 005720 001376 020076
...
$
Восьмеричное число 410 отмечает готовую к выполнению программу, которую могут разделять несколько процессов. (Конкретные магические числа зависят от системы.) Набор разрядов, представляющий 410, не является символом из множества ASCII, поэтому он не может быть создан непреднамеренно такими программами, как редактор. Но, конечно, вы можете создать подобный файл, запустив свою собственную программу, а система в соответствии с соглашением сочтет его выполняемой программой.
В случае текстовых файлов указание может быть скрыто более глубоко в файле, поэтому команда file отыскивает строки, подобные #include, чтобы распознать текст программы на Си, или строки, начинающиеся с точки, чтобы распознать входные данные для программ nroff или troff.
У вас может возникнуть вопрос: почему система не следит за типами файлов более внимательно, ведь тогда, например, программе sort в качестве входного потока никогда не попадал бы файл /bin/ed. Одна из причин состоит в том, чтобы не потерять какие- нибудь полезные для программиста свойства. Хотя команда
$ sort /bin/ed
не имеет особого смысла, существуют команды, которые могут выполняться с любыми файлами, и нет причин ограничивать их возможности. Команды od, cp, wc, cmp, file и многие другие обрабатывают файлы независимо от их содержания. Но идея бестиповых файлов этим не ограничивается. Если, скажем, для программы nroff входные данные отличаются от текста программы на Си, редактор будет вынужден различать их, создавая файл, и, вероятно, считывая файл для редактирования. Тогда, без сомнения, авторам этой книги было бы трудно подготавливать примеры на языке Си для глав 6, 7 и 8.
Система UNIX пытается сгладить все различия. Любой текст состоит из строк, заканчивающихся символом перевода строки, и большинство программ воспринимает такой простой формат. В процессе работы над книгой мы много раз запускали команды для создания текстовых файлов, затем обрабатывали эти файлы с использованием команд, подобных уже рассмотренным, и применяли редактор, чтобы слить файлы во входной поток для форматирующей программы troff, с помощью которой подготовлен текст книги. Практически любая страница здесь получена подобным образом:
$ od -с junk > temp
$ ed ch2.1
1534
r temp
168
...
Команда od передает текст в стандартный выходной поток, который можно использовать там же, где и сам текст. Такая универсальность непривычна; в большинстве систем имеется несколько форматов файла, даже для текста, и требуется диалог с системой со стороны программы или пользователя, чтобы создать файл определенного типа. В системе UNIX есть только один вид файла, и для доступа к такому файлу достаточно лишь знать его имя.[6]
Отсутствие форматов файла дает выигрыш во всем программисты не должны заботиться о типе файла, а все стандартные программы будут работать с любым файлом. Однако необходимо отметить и недостатки. Программы, которые сортируют, редактируют, проводят поиск, действительно ожидают текст в качестве входного потока: команда grep не может правильно анализировать двоичные файлы, команда sort не может сортировать их, и никакой стандартный редактор не может работать с ними.
В большинстве программ, которые ожидают текст в качестве входного потока, существуют ограничения реализации. Мы проверили несколько программ на тексте размером 30 тыс. байт, не содержащем ни одного символа перевода строки, и только некоторые из них работали правильно, поскольку многие программы делают явно неоговариваемые допущения о максимальном размере строки текста (исключительные ситуации см. в разделе BUGS (ошибки) описания sort(1)).
