Литература

Бах Морис. Архитектура операционной системы 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, задающую это значение.

1Использование suid-программ для нарушения защиты – известнейший способ взлома систем. Существует набор строгих правил составления защищенных suid-программ. Самое простое из этих правил (но явно недостаточное) – не давать никому права читать содержимое таких программ. Благодаря этому иногда можно скрыть слабое место программы от посторонних глаз.

1Фоновый процесс при попытке вывода на консоль остановится, получив сигналSIGTTOU(см. главу 6). Следует придумать иной способ оповещения об изменениях файлов.

1Не следует путать это понятие с понятием потока выполнения, когда несколько копий кода могут работать с одним набором данных. Потоки выполнения сейчас доступны в некоторых реализацияхUNIX,и они охватываются последними расширениями стандарта POSIXи спецификации XSI.Тем не менее мы не будем более подробно описывать сложности многопоточной модели. За дальнейшей информацией обратитесь к справочному руководству системы.

1Здесь следует отметить, что значениеargv[0]– не пустая трата памяти, а весьма важный параметр. Во-первых, он напоминает программе ее имя: признаком хорошего стиля программирования считается вывод диагностики от имени программыargv[0], ведь заранее не известно, как впоследствии переименует программу пользователь. Во-вторых, у исполняемого файла может быть несколько имен (вспомните про ссылки), и это можно выгодно использовать. Часто множество утилит на самом деле является одной программой, которая ведет себя по-разному в зависимости от использованного имени. Это кажется странным, но прекрасно работает. Так, программа удаленного выполнения командrsh,будучи названной именем neibor,ведет себя так, как будто ей сообщили дополнительный первый аргумент neibor.Можно заготовить набор псевдонимов этой программы для запуска команд на соседних системах сети.

1Современные системы, согласно спецификации SUSV2и стандарту POSIX,должны также позволять возвращаться от истинных идентификаторов к сохраненным (saved-set-uid, saved-set-gid)действующим идентификаторам пользователя и группы.

1Некоторые из упомянутых сигналов могут отсутствовать в используемой системе, тогда компилятор сообщит о неизвестном мнемоническом имени. Иногда имя сигнала определено, а данный сигнал отсутствует в системе. В ряде случаев требуется определить наличие определенного сигнала на стадии выполнения программы. В этих ситуациях можно воспользоваться советом, приведенным в информативной части стандарта POSIX1003.1: наличие поддержки сигнала сообщает вызов функцииsigaction()с аргументами actиоасt, имеющими значения NULL.

1Спецификация SUSV2приводит для этих сигналов нормальное завершение в качестве действия по умолчанию; лучшими примерами являются сигналы SIGCHLDи SIGURG.

1Тем не менее при написании сложных систем следует знать некоторые дополнительные детали механизма доставки и обработки сигналов (см. стандарт POSIX1003.1, спецификацию SUSV2,и руководство используемой программистом системы).

1На самом деле программа имеет возможность с помощью операций управления ввода/вывода выяснить тип конечного устройства, используемого в качестве стандартного ввода/вывода (файл, терминал или канал). Некоторые стандартные утилиты UNIXведут себя по-разному в разных ситуаций; сравните вывод lsна терминал и в канал.

1В некоторых реализациях вызов selectизменяет также содержимое структуры timeout:оно заполняется оставшимся временем до истечения первоначально заданного интервала. Данную возможность следует учитывать при вызовеselectс нулевыми масками в качестве высокоточного аналога вызова sleep–тогда использование selectв цикле может привести к неправильным результатам.

1В некоторых версиях UNIXесть также возможность примененияобязательных блокировок (mandatory lock).

2Три упомянутые средства часто называют System V IPC,поскольку впервые это семейство межпроцессных взаимодействий было введено в диалекте System V Unix.Стандарт POSIX1003.1 их не описывает; более того. аналогичные POSIX-средства имеют другой интерфейс и семантику. Тем не менее System V IPCвнесены в спецификацию SUSV2как заимствованные из второй версии спецификацииSVID.

1Клинч иногда является следствием гораздо более запутанной ситуации, если установлению блокировки препятствуют одновременно несколько других блокировок.

1В базовом документе POSIX 1003.1 средства IPC System Vне вводятся.

1Более точно порядок разрешения доступа к объекту IPC описан в спецификации SUSV2.

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

1Потоки stdin, stdoutи stderrне следует закрывать: это может привести к аварийному завершению процесса, так как соответствующие структуры TFILEчасто размещены в статической, а не динамической памяти.

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

1Для отладки программ, интенсивно использующих динамическую память, существуют специальные библиотеки, подменяющие стандартный механизм процедур семейства malloc.Эти библиотеки менее производительны, зато выполняют функцию «раннего предупреждения» подобных ошибок, то есть незамедлительно фиксируют нарушения правил работы с динамической памятью.

1Полезно также знать о процедуре setsockopt,управляющей параметрами соединения.

418