Литература
Бах Морис. Архитектура операционной системы UNIX. (http://lib.ru/BACH/)
Богатырев Андрей. Хрестоматия по программированию на Си в Unix. (http://lib.ru/CTOTOR/book.txt)
Голдт С., ван дер Меер С., Буркетт С., Уэлш М. Руководство программиста для Linux. (http:// www.opennet.ru/docs/RUS/Lpg)
Джонсон Майкл. Ядро ОС Linux. Руководство системного программиста. (www.linuxrsp.ru/docs/books/khg.html)
Керниган Б.В., Пайк Р. UNIX – универсальная среда программирования. – М.: Финансы и статистика, 1992. – 304 с.
Полищук А.П., Семериков С.А. Программирование в X Window средствами Free Pascal. (http://freepascal.ru/article//book/xwin/, http://pascal.sources.ru/graph/xwinfpc/)
Робачевский А.М. Операционная система UNIX. – Спб.: БХВ-Петербург, 2000. – 528 с.
Уолтон Шон. Создание сетевых приложений в среде Linux. Руководство разработчика. – М.: Вильямс, 2001. – 464 с.
Хантер Робин. Основные концепции компиляторов. – М.: Издательский дом «Вильямс», 2002. – 256 с.
Хэвиленд К., Грэй Д., Салама Б. Системное программирование в UNIX. Руководство программиста по разработке ПО. – M.: ДМК Пресс, 2000. – 368 с.
Эндрюс Грегори Р. Основы многопоточного, параллельного и распределенного программирования. – М.: Издательский дом «Вильямс», 2003. – 512 с.
Draft Standard for Information Technology – Portable Operating System Interface (POSIX) Part 2: Shell and Utilities (IEEE P1003.2 Draft 11.2 – September 1991)
A.D. Marshall. Programming in C. UNIX System Calls and Subroutines using C.
(http://www.cm.cf.ac.uk/Dave/C/CE.html)
Mark Mitchell, Jeffrey Oldham, and Alex Samuel. Advanced Linux Programming. – New Riders Publishing, 2001. – 340 p.
Steve D. Pate. UNIX Internals: A Practical Approach. – Addison-Wesley, 1996. – 667 p.
Uresh Vahalia. UNIX Internals: The New Frontiers. – Prentice Hall, 1996. – 601 p.
Kurt Wall, Mark Watson, and Mark Whitis. Linux Programming Unleashed. – Sams, 1999. – 847 p.
[1]
Согласно спецификации SUSV2 заголовочный файл limits.h
должен определять константу OPEN_MAX, задающую это значение.
[2]
Использование suid-программ для нарушения защиты – известнейший способ взлома систем. Существует набор строгих правил составления защищенных suid-программ. Самое простое из этих правил (но явно недостаточное) – не давать никому права читать содержимое таких программ. Благодаря этому иногда можно скрыть слабое место программы от посторонних глаз.
[3]
Фоновый процесс при попытке вывода на консоль остановится, получив сигнал SIGTTOU (см. главу 6). Следует придумать иной способ оповещения об изменениях файлов.
[4]
Не следует путать это понятие с понятием потока выполнения, когда несколько копий кода могут работать с одним набором данных. Потоки выполнения сейчас доступны в некоторых реализациях UNIX, и они охватываются последними расширениями стандарта POSIX и спецификации XSI. Тем не менее мы не будем более подробно описывать сложности многопоточной модели. За дальнейшей информацией обратитесь к справочному руководству системы.
[5]
Здесь следует отметить, что значение argv[0] – не пустая трата памяти, а весьма важный параметр. Во-первых, он напоминает программе ее имя: признаком хорошего стиля программирования считается вывод диагностики от имени программы argv[0], ведь заранее не известно, как впоследствии переименует программу пользователь. Во-вторых, у исполняемого файла может быть несколько имен (вспомните про ссылки), и это можно выгодно использовать. Часто множество утилит на самом деле является одной программой, которая ведет себя по-разному в зависимости от использованного имени. Это кажется странным, но прекрасно работает. Так, программа удаленного выполнения команд rsh, будучи названной именем neibor, ведет себя так, как будто ей сообщили дополнительный первый аргумент neibor. Можно заготовить набор псевдонимов этой программы для запуска команд на соседних системах сети.
[6]
Современные системы, согласно спецификации SUSV2 и стандарту POSIX, должны также позволять возвращаться от истинных идентификаторов к сохраненным (saved-set-uid, saved-set-gid) действующим идентификаторам пользователя и группы.
[7]
Некоторые из упомянутых сигналов могут отсутствовать в используемой системе, тогда компилятор сообщит о неизвестном мнемоническом имени. Иногда имя сигнала определено, а данный сигнал отсутствует в системе. В ряде случаев требуется определить наличие определенного сигнала на стадии выполнения программы. В этих ситуациях можно воспользоваться советом, приведенным в информативной части стандарта POSIX 1003.1: наличие поддержки сигнала сообщает вызов функции sigaction() с аргументами act
и оасt, имеющими значения NULL.
[8]
Спецификация SUSV2 приводит для этих сигналов нормальное завершение в качестве действия по умолчанию; лучшими примерами являются сигналы SIGCHLD и SIGURG.
[9]
Тем не менее при написании сложных систем следует знать некоторые дополнительные детали механизма доставки и обработки сигналов (см. стандарт POSIX 1003.1, спецификацию SUSV2, и руководство используемой программистом системы).
[10]
На самом деле программа имеет возможность с помощью операций управления ввода/вывода выяснить тип конечного устройства, используемого в качестве стандартного ввода/вывода (файл, терминал или канал). Некоторые стандартные утилиты UNIX ведут себя по-разному в разных ситуаций; сравните вывод ls на терминал и в канал.
[11]
В некоторых реализациях вызов select изменяет также содержимое структуры timeout: оно заполняется оставшимся временем до истечения первоначально заданного интервала. Данную возможность следует учитывать при вызове select с нулевыми масками в качестве высокоточного аналога вызова sleep – тогда использование select в цикле может привести к неправильным результатам.
[12]
В некоторых версиях UNIX есть также возможность применения обязательных блокировок (mandatory lock).
[13]
Три упомянутые средства часто называют System V IPC, поскольку впервые это семейство межпроцессных взаимодействий было введено в диалекте System V Unix. Стандарт POSIX 1003.1 их не описывает; более того. аналогичные POSIX-средства имеют другой интерфейс и семантику. Тем не менее System V IPC внесены в спецификацию SUSV2 как заимствованные из второй версии спецификации SVID.
[14]
Клинч иногда является следствием гораздо более запутанной ситуации, если установлению блокировки препятствуют одновременно несколько других блокировок.
[15]
В базовом документе POSIX 1003.1 средства IPC System V не вводятся.
[16]
Более точно порядок разрешения доступа к объекту IPC описан в спецификации SUSV2.
[17]
Протокол UDP не гарантирует доставку дейтаграмм; кроме того, может быть нарушен исходный порядок сообщений, допускается также случайное дублирование дейтаграмм. Приложения, использующие протокол UDP, должны обеспечивать контроль данных на прикладном уровне, для этого может потребоваться организация подтверждения доставки и повторной пересылки данных.
[18]
Потоки stdin, stdout
и stderr не следует закрывать: это может привести к аварийному завершению процесса, так как соответствующие структуры TFILE
часто размещены в статической, а не динамической памяти.
[19]
Опытные программисты не советуют использовать функцию fscanf
(scanf) для ввода данных, кроме случаев простого интерактивного ввода. Вместо функции fscanf
(scanf) предлагается использовать комбинацию вызовов fgets (gets) и sscanf. Недостаток функции fscanf
(scanf) в данном случае состоит в том, что при случайном нарушении формата строки вводимых данных эта функция может перейти к чтению следующей строки, поскольку функция fscanf (scanf) не отличает символ окончания строки от других разделителей полей. В такой ситуации сложно обработать ошибку входных данных корректно, а кроме того, ввод следующей строки тоже будет нарушен.
[20]
Для отладки программ, интенсивно использующих динамическую память, существуют специальные библиотеки, подменяющие стандартный механизм процедур семейства malloc. Эти библиотеки менее производительны, зато выполняют функцию «раннего предупреждения» подобных ошибок, то есть незамедлительно фиксируют нарушения правил работы с динамической памятью.
[21]
Полезно также знать о процедуре setsockopt, управляющей параметрами соединения.
