Текст книги "UNIX — универсальная среда программирования"

Автор книги: Брайан Керниган

Соавторы: Роб Пайк
сообщить о нарушении

Текущая страница: 4 (всего у книги 31 страниц) [доступный отрывок для чтения: 12 страниц]

TERM=adm3

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

d=/horribly/long/directory/name

к файлу .profile, чтобы использовать:

$ cd $d

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

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

export MAIL PATH TERM

Подводя итоги, покажем, как может выглядеть типичный файл .profile:

$ cat .profile

stty erase '^h' -tabs

MAIL=/usr/spool/mail/you

PATH=:$HOME:/bin:/usr/bin:/usr/games

TERM=adm3

b=$HOME/book

export MAIL PATH TERM b

date

who | wc -l $

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

1.5 Другие средства UNIX

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

Имеет смысл также периодически заглядывать в руководство, чтобы освежить свои знания об известных вам командах и познакомиться с новыми. В руководстве описывается множество программ, которые мы не обсуждали, включая компиляторы языков программирования, подобные Фортран 77, программы-калькуляторы типа bc(1), cu(1) и uucp(1) – программы для межмашинного взаимодействия, графические пакеты, статистические программы и даже такая программа, как units(1).

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

Историческая и библиографическая справка

Первой публикацией по системе UNIX является статья Д. М. Ритчи и К. Л. Томпсона "The UNIX Time-sharing System" (Communications of the ACM, July, 1974). Она была перепечатана там же в январе 1983 г. (стр. 89 из перепечатки есть в мартовском выпуске 1983 г.). Это обзор системы для специалистов по операционным системам, но мы рекомендуем познакомиться с ним всем программистам.

Специальный июльский выпуск журнала The Bell System Technical Journal (BSTJ) 1978 г. содержит ряд статей, посвященных дальнейшему развитию системы и некоторым историческим вопросам, включая переработанный вариант статьи Ритчи и Томпсона. Следующий специальный выпуск BSTJ, содержащий новые статьи по системе UNIX, вышел в свет в 1984 г.

В статье Б. Кернигана и Д. Мэши "The UNIX Programming Environment" (IEEE Computer Magazine, April, 1981) делается попытка выделить наиболее существенные свойства системы с точки зрения программистов.

В справочном руководстве по системе UNIX, какой бы ни была ваша версия системы, вы найдете команды, системные функции и правила взаимодействия с ними, форматы файлов и процедуры поддержания системы. Вы не сможете обойтись без этого руководства, хотя на первых порах, пока вы не начнете программировать, вам, вероятно, будет достаточно прочесть только часть первого тома. Том 1 справочного руководства по седьмой версии системы опубликован издательством Холта, Райнхарта и Уинстона. Том 2 "Documents for Use with the UNIX Timesharing System" справочного руководства содержит рекомендации по использованию и описания большинства команд. В частности, здесь описываются достаточно подробно средства подготовки документации и разработки программ. В конечном счете, мы уверены, вас заинтересует этот материал.

Хорошим введением для совсем "зеленых" новичков и непрограммистов представляется книга Э. и Н. Ломато "A UNIX Primer" (Prentice-Hall, 1983).

Глава 2
Файловая система

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

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

2.1 Основные сведения о файлах

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

Лучше всего познакомиться с файлами экспериментальным путем, так что начнем с создания небольшого файла:

$ ed а

now is the time,

for all good people

.

w junk

36

q

$ls -l

-rw-r–r– 1 you 26 Sep 27 06:11 junk

$

Здесь junk – это файл из 36 байт, т.е. 36 символов, которые вы ввели (не считая, конечно, символов, введенных при коррекции ошибок). Команда cat показывает содержимое файла в следующем виде:

$ cat junk

now is the time

for all good people

$

Команда od ("octal dump" – восьмеричный дамп) выдает "изображение" всех байтов файла:

$ od -с junk

0000000 n o w   i s   t h e   t i m e n

0000020 f o r   a l l   g o o d   p e o

0000040 p l e n

0000044

$

Флаг -с означает, что следует интерпретировать байты как символы. Если добавить флаг -b, то можно, кроме того, показать байты как восьмеричные числа.[5] 5
  В каждом байте файла находится число, достаточно большое, чтобы закодировать изображаемый символ. В большинстве систем UNIX кодировка называется ASCII ("American Standard Code for Information Interchange" – американский стандартный код для обмена информацией), но на некоторых машинах, особенно произведенных фирмой IBM, используется кодировка, называемая EBCDIC ("Extended Binary Coded Decimal Interchange Code" – расширенная двоично закодированная десятичная общая кодировка). Здесь и далее в книге мы будем применять множество символов ASCII; воспользуйтесь командой cat /usr/pub/ascii или прочтите ascii(7), чтобы узнать восьмеричные значения символов.


[Закрыть]

$ od -cb junk

0000000  n   o   w       i   s       t   h   e       t   i   m   e  n

        156 157 167 040 151 163 040 164 150 145 040 164 151 155 145 012

0000020  f   o   r       a   l   l       g   o   o   d       p   e   o

        146 157 162 040 141 154 154 040 147 157 157 144 040 160 145 157

0000040  d   l   e  n

        160 154 145 012

0000044 $

Семизначные числа в колонке слева показывают место в файле, т.е. порядковый номер следующего изображаемого символа в восьмеричной форме. Между прочим, приоритет восьмеричных чисел – это пережиток времен PDP-11, когда восьмеричной нотации отдавалось предпочтение. Для других машин больше подходит шестнадцатеричная нотация; флаг -х предписывает команде od печатать информацию в шестнадцатеричной форме.

Обратите внимание на то, что после каждой строки идет символ с восьмеричным значением 012. Это символ перевода строки для ASCII; система помещает его во входной поток, когда вы нажимаете клавишу RETURN. По соглашению, заимствованному из языка Си, символ перевода строки изображается как n, что лишь облегчает чтение. Такого соглашения придерживаются только программы типа od; в файле же хранится единственный байт 012.

Перевод строки – наиболее типичный пример специального символа. Другими специальными символами, связанными с некоторыми операциями управления терминалом, являются символы: шаг назад (восьмеричное значение 010 изображается как b), табуляция (011, t), возврат каретки (015, r).

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

Если ввести последовательность

←

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

При выводе файла, содержащего символ ←, он передается на терминал без обработки, что опять приводит к передвижке курсора на одну позицию назад. Если воспользоваться командой od, чтобы вывести файл, содержащий символ ←, он появится как байт со значением 010 или, если указан флаг -с, как b.

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

$ stty = tabs

приводит к замене символов табуляции пробелами при выводе на терминал см. описание stty(1).

Обработка символа RETURN аналогична рассмотренной выше. Ядро отображает RETURN на терминале как "возврат каретки" и "конец строки", но во входной поток попадает только "перевод строки". При выводе этот символ вновь заменяется символами возврата каретки и конца строки.

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

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

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

Программы выбирают данные из файла с помощью системного обращения с именем 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] 6
  Существует хороший тест на единообразие системы, предложенный Д. МакИлроем. UNIX легко выдерживает его. Можно ли результат компиляции с Фортрана использовать как входной поток для компилятора с Фортрана? Очень больше число систем не позволяет этого сделать.


[Закрыть]

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

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

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