Брайан Керниган - UNIX — универсальная среда программирования

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

Для диалоговых программ, подобных p, systemдолжна тем не менее вновь связать стандартный входной и выходной потоки с терминалом, в частности /dev/tty.

Системный вызов dup(fd)дублирует дескриптор файла fdна незанятый дескриптор файла с наименьшим номером и возвращает новый дескриптор, ссылающийся на тот же самый открытый файл. Следующая программа "присоединяет" стандартный входной поток программы к файлу:

int fd;

fd = open("file", 0);

close(0);

dup(fd);

close(fd);

Вызов close(fd)освобождает дескриптор файла 0 (стандартный входной поток), но, как правило, не влияет на процесс-родитель. Здесь приведена наша версия systemдля диалоговых программ, использующая prognameдля вывода сообщений об ошибках. Вам следует игнорировать те части функции, которые имеют дело с сигналами (мы вернемся к ним позднее).

/*

* Safer version of system for interactive programs

*/

#include

#include

system(s) /* run command line s */

char *s;

{

int status, pid, w, tty;

int (*istat)(), (*qstat)();

extern char *progname;

fflush(stdout);

tty = open("/dev/tty", 2);

if (tty == -1) {

fprintf(stderr, "%s: can't open /dev/tty\n", progname);

return -1;

}

if ((pid = fork()) == 0) {

close(0);

dup(tty);

close(1);

dup(tty);

close(2);

dup(tty);

close(tty);

execlp("sh", "sh", "-c", s, (char*)0);

exit(127);

}

close(tty);

istat = signal(SIGINT, SIG_IGN);

qstat = signal(SIGQUIT, SIG_IGN);

while ((w = wait(&status)) != pid && w != -1)

;

if (w == -1)

status = -1;

signal(SIGINT, istat);

signal(SIGQUIT, qstat);

return status;

}

Отметим, что /dev/ttyоткрыта с режимом 2 — чтение и запись. С помощью dupформируются стандартный входной и выходной потоки. Здесь можно провести аналогию со сборкой системой стандартных входного и выходного потоков и потока ошибок, когда вы в нее входите. Поэтому в ваш стандартный входной поток можно писать:

$ echo hello 1>&0

hello

$

Это означает, что вам следует применить dupк дескриптору файла 2, чтобы вновь связать стандартные ввод и вывод, но открытие /dev/ttyявляется более естественным и безопасным. Даже systemимеет потенциальные проблемы: открытые файлы в вызывающей программе, такие, как ttyв подпрограмме ttinпрограммы p, будут передаваться процессу-потомку.

Смысл изложенного выше состоит не в том, что вы должны использовать нашу версию systemдля своих программ (она могла бы разрушить недиалоговый ed, например), а в том, чтобы понять, как управляют процессами и корректно используют примитивы; значение слова "корректно" меняется в зависимости от приложения и может быть не согласовано со стандартной реализацией system.

Теперь мы рассмотрим работу с сигналами извне (такими, как прерывания) и ошибками программы. Последние возникают главным образом из-за некорректных обращений к памяти, выполнения привилегированных команд или при выполнении операций с плавающей запятой. Наиболее распространенными внешними сигналами являются прерывание , посылаемый при печати символа del , выйти , генерируемый символом FS ( ctrl-\ ), отбой , вызываемый завершением телефонной связи, и закончить, генерируемый командой kill. Когда происходит одно из этих событий, посылается сигнал всем процессам, запущенным с того же терминала, и если не были приняты другие меры, процесс завершается. Для большинства сигналов пишется файл образа памяти, который может потребоваться при поиске ошибок (см. справочное руководство по adb(1), sdb(1)).

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

#include

signal(SIGINT, SIG_IGN);

Специфицирует игнорирование прерываний, тогда как

signal(SIGINT, SIG_DEL);

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

#include

char *tempfile = "temp.xxxxxx";

main() {

extern onintr();

if (signal(SIGINT, SIG_IGN) != SIG_IGN)

signal(SIGINT, onintr);

mktemp(tempfile);

/* Process ... */

exit(0);

}

onintr() { /* почистить, если прервано */

unlink(tempfile);

exit(1);

}

Почему в mainимеют место проверки и двойной вызов signal? Вспомните, что сигналы посылаются всем процессам, запущенным с данного терминала. Соответственно если программа должна быть запущена не в диалоговом режиме (с помощью &), shellделает так, что она будет игнорировать прерывания. Поэтому сигналы прерывания, посланные основным процессам, не остановят ее. Если бы эта программа началась с объявления о том, что все прерывания, которые должны быть посланы подпрограмме onintr, не принимаются во внимание, были бы сведены на нет все усилия shellзащитить ее при запуске в фоновом режиме.

Решение, показанное выше, состоит в том, чтобы проверить состояние обработки прерываний, если они игнорировались ранее. Функции программы в том виде, в каком она написана, зависят от возвращаемого signalпредыдущего состояния конкретного сигнала. Если сигналы уже игнорировались, процесс должен продолжить это дело; в противном случае их следует перехватывать.

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