Читаем Искусство программирования для Unix полностью

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

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

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

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

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

7.2.1.1. Учебный пример: пользовательский почтовый агент mutt

Пользовательский почтовый агент mutt является современным представителем наиболее важной традиции проектирования программ для обработки электронной почты в Unix. Данная программа имеет простой экранный интерфейс с одноклавишными командами для просмотра и чтения почты.

Если mutt используется для создания почтовых сообщений (либо если данная программа вызвана с адресом в качестве аргумента командной строки или с помощью одной из команд для создания ответного сообщения), то программа определяет значение переменной EDITOR, а затем генерирует имя временного файла. Значение данной переменной используется как команда, а имя временного файла как ее аргумент''. Когда запущенная таким образом программа прекращает свою работу, mutt возобновляет управление, предполагая, что временный файл содержит необходимый текст сообщения.

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

Важным вариантом такой стратегии является вызов с созданием подоболочки небольшой программы-посредника, передающей специальное задание уже запущенному экземпляру большой программы, такой как редактор или Web-браузер. Поэтому разработчики, на Х-диснлеях которых обычно уже имеется запущенный экземпляр редактора emacs, могут установить переменную EDITOR*emacsclient и в случае необходимости редактировать сообщение в mutt открывать данные буфера в emacs. Целью данного подхода является не экономия памяти или других ресурсов, а предоставление пользователю возможности объединять все редактирование в одном emacs-процессе (поэтому, например, при вырезании и вставке между буферами можно было переносить внутренние параметры emacs, такие как выделение шрифта).

7.2.2. Каналы, перенаправление и фильтры

Перейти на страницу:

Похожие книги

Программист-прагматик. Путь от подмастерья к мастеру
Программист-прагматик. Путь от подмастерья к мастеру

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

А. Алексашин , Дэвид Томас , Эндрю Хант

Программирование / Книги по IT
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

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

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT