Храмцов П.Б. Открытые системы

Подождите немного. Документ загружается.

Для написания программ, оперирующих с сущностями POSIX-

совместимых систем, применяются командный интерпретатор (язык

shell) и/или компилируемый язык C. В первом случае приложение может

пользоваться служебными программами (утилитами), во втором -

функциями. Функциональный интерфейс операционных систем

естественно считать первичным, поскольку большинство служебных

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

По этой причине далее мы будем рассматривать преимущественно

уровень функций.

Основными операциями, применимыми к объектам ОС, являются

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

избирательно разрешать и запрещать осуществление подобных

операций. Ранее в стандарте фигурировало понятие суперпользователя,

не подверженного контролю прав доступа. В POSIX-2001 выбрана более

гибкая формулировка - "имеющий соответствующие привилегии", что

отражает прогресс в реализации ОС с расщеплением

суперпользовательских возможностей.

В POSIX-совместимых ОС определены объекты, которые можно

назвать вспомогательными; они помогают организовать взаимодействие

между основными сущностями. Особенно широк спектр средств

межпроцессного взаимодействия.

Процессы выполняются в определенном окружении, частью

которого является языково-культурная среда (Locale), образованная

такими категориями, как символы и их свойства, форматы сообщений,

дата и время, числовые и денежные величины.

Как правило, с процессом ассоциированы по крайней мере три

файла - стандартный ввод, стандартный вывод, стандартный протокол.

Обычно стандартный ввод назначается на клавиатуру терминала, а

стандартный вывод и стандартный протокол - на экран. Со стандартного

ввода читаются команды и (иногда) исходные данные для них. На

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

стандартный протокол помещаются диагностические сообщения.

К операционным системам могут предъявляться качественные

требования, например, требование поддержки реального времени:

способность обеспечить необходимый сервис в течение заданного

отрезка времени.

Среда компиляции POSIX-совместимых приложений

Как правило (хотя это и не всегда осознается), разработка

приложений ведется в кросс-режиме, то есть платформа разработки

(эквивалентный термин - инструментальная платформа) не совпадает с

платформой выполнения (называемой также целевой платформой). На

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

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

выполнения на целевую платформу.

Важнейшая часть среды компиляции - заголовочные (или

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

символических констант, макросов, типов данных, структур и т.п. Для

каждой описанной в стандарте POSIX функции определено, какие

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

приложением (обычно требуется один файл).

Выше было указано, что посредством символических констант,

определенных в заголовочном файле <unistd.h>, операционная система

предоставляет приложению информацию о поддерживаемых

возможностях. Стандартом POSIX предусмотрен симметричный

механизм, называемый механизмом макросов проверки возможностей,

он позволяет приложениям объявлять о своем желании получить доступ

к определенным прототипам и именам.

Основным макросом проверки возможностей является

_POSIX_C_SOURCE. Среди требований к приложениям, строго

соответствующим стандарту POSIX, фигурирует необходимость

определения символической константы _POSIX_C_SOURCE со

значением 200112L до включения каких-либо заголовочных файлов.

Таким образом POSIX-совместимое приложение заявляет, что ему

нужны POSIX-имена. Близкую по смыслу роль играет макрос

_XOPEN_SOURCE (со значением 600).

Примером использования макроса _POSIX_C_SOURCE во

включаемых файлах ОС Linux может служить фрагмент, приведенный

на листинге 1.2.

#if defined(_REENTRANT) || (_POSIX_C_SOURCE - 0 >= 199506L)

#define LIBXML_THREAD_ENABLED#endif

Листинг 1.2. Пример использования макроса проверки

возможностей _POSIX_C_SOURCE.

Стандартом POSIX предусмотрены некоторые меры для решения

важной и трудной проблемы (вызванной в первую очередь необъектным

характером языка C), заключающейся в отсутствии пересечений по

именам между приложением и операционной системой. Префиксы

posix_, POSIX_ и _POSIX_ зарезервированы для нужд стандарта.

С подчеркивания, за которым следует еще одно подчеркивание

или заглавная латинская буква, могут начинаться только системные (но

не прикладные) имена. Для включаемых файлов описаны префиксы

используемых в них имен. Например, для операций управления

файлами, фигурирующих в <fcntl.h>, в качестве префиксов

задействованы F_, O_, S_. У средств межпроцессного взаимодействия,

описанных в файле <sys/ipc.h>, префиксом служит IPC_. К сожалению,

заголовочных файлов много, а какая-то общая дисциплина именования

отсутствует вследствие исторических причин. Так, для

манипулирования характеристиками терминалов в файле <termios.h>

определено множество разнообразных имен: EXTB, VDSUSP,

DEFECHO, FLUSHO и т.п. Еще имеется четыреста семнадцать имен

типа _Exit, abort, abs, acos и т.д., которые могут участвовать в

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

прикладной программист может случайно "перебить" системный

макрос, внешнюю переменную или функцию, поэтому целесообразно

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

тщательно изучать выдаваемые ими сообщения.

Мобильность POSIX-совместимых приложений

Мобильность приложений, соответствующих стандарту POSIX,

принципиально достижима благодаря двум основным факторам. Во-

первых - это наличие огромного числа стандартизованных системных

сервисов, а во-вторых - возможность динамического выяснения

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

(Естественно, мы имеем в виду мобильность в рамках,

регламентируемых стандартом.)

Приложения, соответствующие стандарту POSIX, могут быть

одно- и многопроцессными, с возможностью динамической адаптации

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

средства порождения и завершения процессов, смены их программ,

опроса и/или изменения разнообразных характеристик. Процессы можно

приостанавливать и активизировать в заданное время. Механизм

сигналов позволяет извещать о событиях и завершать процессы

внешним образом. Для их группирования предусмотрены средства

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

управления планированием и приоритетами процессов. Широк спектр

средств межпроцессного взаимодействия (очереди сообщений,

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

пределах процесса можно организовать несколько потоков управления.

Необходимая степень детерминизма выполнения достигается

благодаря средствам поддержки реального времени (к ним относятся

управление дисциплиной выделение процессоров, сигналы реального

времени, удержание страниц в оперативной памяти, таймеры высокого

разрешения и т.д.).

Функции для работы с файлами удовлетворяют потребности

приложений в чтении и записи долговременных данных, защите таких

данных от несанкционированного доступа. Механизм блокировки

фрагментов файлов позволяет обеспечить атомарность транзакций.

Асинхронный ввод/вывод дает возможность совмещать операции

обмена, оптимизируя тем самым приложения. С помощью множества

служебных программ можно относительно легко организовать сложную

обработку данных.

В стандарте POSIX тщательно проработаны вопросы доступа к

внешним устройствам, подсоединенным по последовательным линиям,

особенно к терминалам. Возможно, в большей детализации нуждаются

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

магнитная лента.

Стандартизованный командный язык shell - адекватное средство

для написания небольших мобильных процедур и их быстрой

интерактивной отладки. Выделим механизм конвейеров, позволяющий

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

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

выполнения для shell-процедур. За счет фонового режима можно

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

взаимодействие с ними посредством обычного терминала без

многооконных возможностей (впрочем, окна, несомненно, не помешали

бы).

POSIX стандартизует интерфейс командной строки. В принципе,

он достаточен, в меру удобен и, что важно, создает минимум проблем с

точки зрения мобильности. Вероятно, в будущих версиях стандарта

будет регламентирован графический интерфейс, но, безусловно, это

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

приложений.

Языково-культурная среда - одно из важнейших понятий

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

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

пользователей.

Для многопользовательских систем требуется организация

взаимодействия большого числа людей. POSIX решает эту проблему,

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

информацией.

Стандартом POSIX предусмотрены базовые средства поддержки

разработки (в первую очередь - для языка C), что, конечно, не снижает

потребности в специализированных, развитых системах, когда речь идет

о работе с действительно большими программными проектами.

Приложениям предоставляются стандартизованные средства для

выяснения как "крупноблочных" характеристик целевой системы

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

и более мелких характеристик (текущий размер свободного дискового

пространства).

Проблема мобильности приложений чрезвычайно сложна, и было

бы преувеличением утверждать, что стандарт POSIX-2001 решает ее

полностью. Во-первых, за его рамками остаются такие важнейшие

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

Во-вторых, в регламентируемых областях присутствуют "белые пятна"

неспецифицированного поведения реализаций. Тем не менее,

подчеркнем это еще раз, следование стандарту POSIX - обязательный

элемент современной дисциплины разработки прикладных систем.

Основные понятия языка shell

В дальнейшем изложении слово shell будет употребляться в двух

смыслах - как имя языка программирования и как название командного

интерпретатора.

Для нас shell важен прежде всего как мощный язык мобильного

программирования. Предваряя дальнейшее изложение, отметим

имеющиеся в нем возможности комбинирования команд с помощью

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

выполнения команд, генерации имен файлов по шаблонам.

Свойства shell как интерактивного командного интерпретатора,

непосредственно взаимодействующего с пользователем, хранение и

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

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

пользовательский интерфейс строится на иной основе.

Выделим основные понятия языка shell на лексическом уровне.

Под пробелом в дальнейшем понимается не только собственно

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

Слово - это лексема, отличная от знака операции.

Имя - последовательность букв, цифр, символов подчеркивания,

начинающаяся с буквы или подчеркивания.

Параметр - имя, цифра или любой из символов *, @, #, ?, -, $, !.

Комментарий - лексема, начинающаяся с символа #, а также вся

последующая часть строки.

На синтаксическом уровне различаются несколько видов команд.

Простая команда - последовательность полей с разделителями

(обычно пробелами) между ними. Первое поле определяет имя команды,

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

присваиваемых параметрам и перенаправления ввода/вывода (см. далее),

передаются команде в качестве аргументов. Имя команды передается

как аргумент 0.

Значение простой команды - ее код завершения.

Команда - это либо простая команда, либо одна из управляющих

конструкций (см. далее). Кодом завершения команды является код

завершения последней выполненной простой команды.

Конвейер - последовательность команд, разделенных знаком |.

Стандартный вывод всех команд, кроме последней, направляется на

стандартный ввод следующей команды конвейера. Каждая команда

выполняется как самостоятельный процесс; shell ожидает завершения

последней команды, код завершения которой становится кодом

завершения конвейера. Формально будем считать простую команду

частным случаем конвейера.

Список - последовательность из одного или нескольких

разделенных символами ;, &, && или || конвейеров, она может

заканчиваться символами ; или &. Из четырех указанных операций ; и &

имеют равные приоритеты, меньшие, чем у && и ||. Приоритеты

последних также равны между собой. Символ ; означает, что конвейеры

будут выполняться последовательно, а & - параллельно (т. е. shell не

ожидает завершения конвейера). Операция && (||) означает, что список,

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

завершения предыдущего конвейера нулевой (ненулевой). В списке в

качестве разделителя конвейеров вместо символа ; можно использовать

символ перевода строки.

Командная строка - строка текста на языке shell.

Shell-процедура - файл, содержащий программу на языке shell.

Для выполнения (почти) каждой простой команды shell порождает

отдельный процесс, в рамках которого выполняется программа,

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

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

собой shell-процедуру - содержать текст на языке shell.

Далее при описании синтаксиса конструкций языка shell и способа

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

соглашения:

• в квадратные скобки заключаются необязательные части

конструкций;

• многоточие означает повторение предыдущей части конструкции

произвольное число раз.

Конвейеры и примеры их использования

Конвейер - одна из самых красивых конструкций ОС Unix,

вошедшая, разумеется, и в стандарт POSIX. Идея его проста, но на

редкость продуктивна. С помощью конвейеров удается комбинировать

возможности, предоставляемые разными командами, получая по

существу новое качество.

Например, утилита ls не подсчитывает число файлов в каталоге, а

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

программа wc способна подсчитать число строк в файле, но не имеет

отношения к распечатке содержимого каталогов. Если же построить

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

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

листинг 2.1) на нашей установке ОС Linux будет число 92 (утилита wc,

вызванная без аргументов, обрабатывает файл стандартного ввода,

который в данном случае является результатом работы команды ls).

Значит, в каталоге /bin 91 файл, если считать и элементы,

соответствующие текущему и вышележащему каталогам (первая строка

выдачи ls содержит суммарное число блоков, занятых файлами

каталога).

ls -al /bin | wc -l

Листинг 2.1. Пример конвейера.

Еще один пример. Пусть необходима информация о файлах

текущего каталога, модифицированных в октябре. К цели ведет

конвейер, показанный в листинге 2.2:

ls -al | grep "Oct "

Листинг 2.2. Еще один пример конвейера.

Служебная программа grep играет здесь роль фильтра, который

пропускает для вывода только часть строк, выдаваемых ls.

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

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

2.3):

ls -al | grep "Oct " | wc -l

Листинг 2.3. Пример трехступенчатого конвейера.

Здесь утилиту grep с еще большим правом можно назвать

фильтром.

Приведем еще один пример конвейера, полезного, когда нужна

подробная информация о большом каталоге (см. листинг 2.4):

ls -Rl /dev | more

Листинг 2.4. Конвейер для поэкранного просмотра

результатов.

Связующее звено между последовательными компонентами

конвейера называется каналом. Иными словами, для интерпретации

конвейера shell создает временный файл типа "канал", с одного конца в

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

программы tee можно организовать ответвление канала, т. е. помещать

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

tee файл ...

Например, если нужно не только подсчитать число файлов из

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

информацию о них в файл для последующего анализа, следует

построить четырехступенчатый конвейер (см. листинг 2.5):

ls -al | grep "Oct" | tee /tmp/tmpinf | wc -l

Листинг 2.5. Четырехступенчатый конвейер.

В результате его выполнения на экране появится сообщение о

количестве нужных файлов, а в файле /tmp/tmpinf - информация о них.

Переменные и аргументы shell-процедур

Переменные обозначаются именами. Значения могут

присваиваться им привычным способом, то есть посредством команд

вида:

имя=значение [имя=значение] ...

Все значения в языке shell трактуются как текстовые. Подчеркнем,

что, в соответствии с этими требованиями, конструкция

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

должна представлять собой одно слово - в ней не может быть

пробелов.

Обычно в языках программирования ясно из контекста, где

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

оператора присваивания обычно используется имя, в правой - значение.

В shell все не так. Переход от имени переменной к значению помечается

посредством явной операции $. Если в команде встречается конструкция

$имя

то вместо нее интерпретатор shell подставляет значение

переменной с указанным именем. Допускается и запись

${имя}

с тем же смыслом, если нужно отделить имя от последующего

текста.

Рассмотрим пример. После выполнения команд (см. листинг 2.6) -

утилита echo (эхо) выдает на стандартный вывод свои аргументы - на

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

2.7).

a=value_of_variable

b=1+2

echo a = $a

echo b = $b

Листинг 2.6. Присваивание и извлечение значение

переменных.

a = value_of_variable

b = 1+2

Листинг 2.7. Результат вывода значений переменных.

Значения формальных аргументов shell-процедур обозначаются

как

$цифра

$0 - это имя интерпретируемой shell-процедуры. Если заданных

при вызове команды фактических аргументов меньше, чем 9, "лишние"

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

добраться до фактических аргументов с номерами большими, чем 9,

будет сказано ниже (см. управляющую конструкцию for и команду shift).

В качестве примера рассмотрим shell-процедуру, которая выдает

на стандартный вывод свое имя и значения трех первых аргументов (см.

листинг 2.8).

echo Имя команды: $0

echo Значение первого аргумента: $1

echo Значение второго аргумента: $2

echo Значение третьего аргумента: $3

Листинг 2.8. Пример shell-процедуры.

Пусть приведенный текст помещен в файл с именем three_args.

Тогда после выполнения команды (см. листинг 2.9) на экране появится

ее результат (см. листинг 2.10).

three_args arg1 . - arg4

Листинг 2.9. Пример вызова shell-процедуры с аргументами.

Имя команды: three_args

Значение первого аргумента: arg1

Значение второго аргумента: .

Значение третьего аргумента: -

Листинг 2.10. Результат выполнения shell-процедуры.

Поскольку в тексте shell-процедуры упомянуты только первые 3

аргумента, значения аргументов с большими номерами (даже если они

заданы, как в приведенном примере) не влияют на ее работу.

Команда

three_args arg1 --

выдаст другой результат (см. листинг 2.11):

Имя команды: three_args

Значение первого аргумента: arg1

Значение второго аргумента: --

Значение третьего аргумента:

Листинг 2.11. Еще один результат выполнения shell-

процедуры.

Значение третьего формального аргумента пусто.

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

вызвана заданная в ней команда, строку обрабатывает shell,

выполняющий в ней некоторые подстановки. С одной из них - значения

переменной вместо конструкции $имя - мы уже познакомились. Язык

shell содержит ряд аналогичных конструкций. Рассмотрим их.

Там, где в командной строке встречается запись вида

${имя:-слово}

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

именем, если это значение непусто, в противном случае подставляется

слово. Например, при наличии в shell-процедуре присваивания

initdir=${1:-/}

переменная initdir получит значение первого аргумента, если оно

непусто. Если же процедуру вызвали без аргументов, значением initdir

станет символ /. Подобные конструкции - удобный способ

использования подразумеваемых значений.

Запись вида

${имя:=слово}

влечет присваивание нового значения (слово) переменной с

заданным именем, только если ее старое значение не установлено или

пусто (удобный способ присваивания переменным подразумеваемых

значений). Вместо всей конструкции в командную строку подставляется

итоговое (непустое старое или присвоенное новое) значение

переменной.

Конструкция

${имя:?слово}

предназначена для выдачи в стандартный протокол сообщения об

ошибке, если значение переменной с заданным именем не установлено

или пусто, после чего неинтерактивный shell завершает работу с

ненулевым кодом возврата. Непустое значение подставляется в

командную строку, и интерпретация командного файла продолжается

обычным образом.

Вместо конструкции

${имя:+слово}

подставляется слово, если значение переменной с заданным

именем непусто; в противном случае не подставляется ничего. Такой

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

Если в приведенных выше конструкциях опустить двоеточие,

будет отменена проверка непустоты значения (останется лишь проверка

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

остальном смысл конструкций остается прежним.

Shell содержит базовые средства для обработки цепочек символов.

Так, вместо конструкции

${#имя}

подставляется число символов в значении переменной с заданным

именем.

Предоставляется четыре конструкции для сопоставления с

образцом:

${имя%слово}

${имя%%слово}

${имя#слово}

${имя##слово}

Во всех случаях слово рассматривается как образец (шаблон, см.

далее); после сопоставления с ним подставляется значение переменной с

заданным именем, из которого удален минимальный (максимальный)

сопоставленный суффикс (префикс).

Приведем несколько примеров. Для их понимания достаточно

знать, что шаблон * сопоставляется с произвольной цепочкой символов,

в том числе с пустой.

После присваивания переменной

HOME=/home/galat

команда

echo ${#HOME}

выдаст 11.

Заменить в имени файла суффикс .f на .for можно с помощью

команд, показанных в листинге 2.12:

f=file.f