Текст книги "Linux программирование в примерах"

Автор книги: Арнольд Роббинс

сообщить о нарушении

Текущая страница: 53 (всего у книги 55 страниц)

Упражнения

1. Откомпилируйте одну из ваших программ с помощью GCC, используя как -g, так и -O. Запустите ее под GDB, установив контрольную точку в main(). Выполните программу пошагово и посмотрите, насколько близко соответствует (или не соответствует) исполнение оригинальному исходному коду. Это особенно хорошо делать с кодом, использующим циклы while или for.

2. Прочитайте об особенности GDB условной контрольной точки. Насколько это упрощает работу с проблемами, которые появляются лишь после того, как будет сделано определенное число операций?

3. Перепишите функцию parse_debug() из раздела 15.4.2.1 «Добавляйте отладочные опции и переменные», чтобы использовать таблицу строк опций отладки, значений флагов и длин строк

4. (Трудное.) Изучите исходный код gawk; в частности, структуру NODE в awk.h. Напишите вспомогательную отладочную функцию, которая выводит содержимое NODE, основываясь на значении в поле type.

5. Возьмите одну из своих программ и измените ее так, чтобы использовать библиотеку dbug. Откомпилируйте ее сначала без -DDBUG, чтобы убедиться, что она компилируется и работает нормально. (Есть ли у вас для нее набор возвратных тестов? Прошла ли ваша программа все тесты?)

Убедившись, что добавление библиотеки dbug не нарушает работу вашей программы, перекомпилируйте ее с -DDBUG. По-прежнему ли проходит ваша программа все свои тесты? Какова разница в производительности при включенной и отключенной библиотеке? Запустите ваш тестовый набор с опцией -#t, чтобы увидеть трассировку вызовов функций. Как вы думаете, это поможет вам в будущем, когда придется иметь дело с отладкой? Почему да или почему нет?

6. Запустите одну из своих программ, использующих динамическую память, с Electric Fence или одним из других тестеров динамической памяти. Опишите проблемы, которые вы обнаружили, если они есть.

7. Перезапустите ту же самую программу, используя Valgrind с включенным режимом проверки утечек. Опишите найденные вами проблемы, если они есть.

8. Разработайте набор тестов для программы mv. (Прочтите mv(1): убедитесь, что охватили все ее опции.)

9. Поищите в Интернете ресурсы по тестированию программного обеспечения. Какие интересные вещи вы нашли?

Глава 16
Проект, связывающий все воедино

В первой половине этой книги мы довольно аккуратно связали все, что было представлено, рассмотрев V7 ls.c. Однако, нет достаточно небольшой программы, насколько бы это нам хотелось, чтобы связать воедино все концепции и API, представленные начиная с главы 8 «Файловые системы и обходы каталогов».

16.1. Описание проекта

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

Настоящие оболочки являются большими и беспорядочными творениями. Они должны иметь дело со многими проблемами переносимости, такими, которые мы обрисовывали по всей книге, а помимо этого, они часто должны обходить различные ошибки в различных версиях Unix Более того, чтобы быть полезными, оболочки делают множество вещей, которые не затрагивают API системных вызовов, такие, как хранение переменных оболочки, историю сохраненных команд и т.д. Предоставление завершенного обзора полноценной оболочки, такой как Bash, ksh93 или zsh, потребовало бы отдельной книги.

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

1. Спроектируйте свой командный «язык», чтобы его было легко интерпретировать с помощью простого кода. Хотя технология компиляторов и интерпретаторов полезна при написании оболочки как изделия, для вас на данный момент это, вероятно, излишне.

Рассмотрите следующие моменты:

 • Собираетесь ли вы использовать возможности интернационализации?

 • Какие команды должны быть встроены в оболочку?

 • Чтобы быть полезной, в вашей оболочке должен быть механизм пути поиска команд, аналогичный $PATH в обычной оболочке. Как вы его установите?

 • Какие перенаправления ввода/вывода вы хотите поддержать? Только файлы? Также и каналы? Хотите ли вы иметь возможность перенаправлять нет только дескрипторы файлов 0, 1 и 2?

 • Решите, как будут работать кавычки: одинарные и двойные? Или лишь одна разновидность? Как вы поместите в кавычки сами кавычки? Как кавычки будут взаимодействовать с перенаправлениями ввода/вывода?

 • Как вы обработаете вызов команд в фоновом режиме? Что насчет ожидания завершения работы команды в фоновом режиме?

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

 • Какую разновидность символов подстановки или других расширений будете вы поддерживать? Как это взаимодействует с кавычками? С переменными оболочки?

 • Вы должны запланировать по крайней мере операторы if и while. Спроектируйте синтаксис. Мы будем называть их блочными операторами.

 • Решите, хотите ли вы разрешить перенаправления ввода/вывода для блочных операторов. Если да, как будет выглядеть синтаксис?

 • Решите, как язык вашей оболочки должен обрабатывать сигналы, если он вообще это делает.

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

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

3. Для настоящей работы начните просто. Начальная версия должна читать одну строку за раз и разделять ее на слова для использования в качестве отдельных аргументов. Не используйте кавычек, перенаправления ввода-вывода или что-нибудь еще. Не старайтесь даже создать новый процесс для запуска введенной программы. Как вы собираетесь тестировать то, что у вас пока есть?

4. Добавьте кавычки так, чтобы отдельные «слова» могли содержать разделители. Реализует ли код для кавычек ваш проект?

5. Заставьте работать ваши встроенные команды. (По крайней мере две нужные встроенные команды см. в разделах 4.6 «Создание файлов» и 8.4.1 «Смена каталога: chdir() и fchdir()».) Как вы собираетесь их тестировать?

6. Первоначально используйте фиксированный путь поиска, такой как "/bin:/usr/bin:/usr/local/bin". Добавьте создание процесса при помощи fork() и его исполнение при помощи exec(). (См. главу 9 «Управление процессами и каналы».) Запустив новую программу, оболочка должна ждать ее завершения.

7. Добавьте фоновое исполнение и, в качестве отдельной команды, ожидание завершения выполнения процесса (см. главу 9 «Управление процессами и каналы»).

8. Добавьте устанавливаемый пользователем путь поиска (см. раздел 2.4 «Переменные окружения»).

9. Добавьте перенаправление ввода/вывода для файлов (см. раздел 9.4 «Управление дескрипторами файлов»).

10. Добавьте переменные оболочки. Протестируйте их взаимодействие с кавычками.

11. Добавьте символы подстановки и другие расширения (см. раздел 12.7 «Расширения метасимволов»). Протестируйте их взаимодействие с переменными оболочки. Протестируйте их взаимодействие с кавычками.

12. Добавьте конвейеры (см. раздел 9.3 «Базовое межпроцессное взаимодействие: каналы и очереди FIFO»). С этого момента начинаются настоящие сложности. Вам может потребоваться тщательно рассмотреть то, как вы управляете данными, представляющими запускаемые команды.

Здесь можно было бы остановиться с законным чувством достижения, если вы получили работающую оболочку, которая может делать все, упомянутое до сих пор.

13. Если вы принимаете дальнейший вызов, добавьте операторы if и/или while.

14. Добавьте обработку сигналов (см. главу 10 «Сигналы»).

15. Если вы хотели бы использовать свою оболочку для настоящей работы, изучите библиотеку GNU Readline (наберите в системе GNU/Linux 'info readline' или посмотрите исходный код для оболочки Bash). Эта библиотека дает вам возможность добавлять к интерактивным программам возможность редактирования командной строки в стиле Emacs или vi.

Постоянно держите в уме две вещи– всегда имейте возможность протестировать то, что вы делаете; и «никаких произвольных ограничений»!

Когда все это сделано, проделайте анализ сделанного проекта. Как вы сделали бы его по-другому во второй раз? Удачи!

16.2. Рекомендуемая литература

1. The UNIX Programming Environment, by Brian W. Kernighan and Rob Pike. Prentice-Hall, Englewood Cliffs, New Jersey, USA, 1984. ISBN: 0-13-937699-2.[190]190
  Русский перевод Брайан Керниган, Роб Пайк. UNIX: Программное окружение. Санкт-Петербург. Символ-Плюс, 2003 – Примеч. науч. ред.


[Закрыть]

Эта классическая книга по программированию на Unix, описывающая целостную структуру окружения Unix, от интерактивного использования до программирования оболочки, программирования с помощью функций и низкоуровневых системных вызовов, разработки программ с помощью make, yacc и lex, и документирования с помощью nroff и troff.

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

2. The Art of UNIX Programming, by Eric S. Raymond. Addison-Wesley, Reading, Massachusetts, USA, 2004. ISBN: 0-13-142901-9.

Это книга на более высоком уровне фокусируется на проблемах проектирования при программировании в Unix: как работают программы Unix и как разрабатывать свои собственные программы, чтобы уютно вписаться в окружение Linux/Unix. Хотя мы не всегда согласны со многим из того, что хочет сказать автор, книга действительно содержит значительное количество важного материала, и ее стоит прочесть.

Часть 4
Приложения

Приложение А
Научитесь программированию за десять лет

«Опыт, сущ.: Нечто, что вы не получаете до тех пор, пока это вам не понадобится».

– Оливер -

Данная глава написана Петером Норвигом (Peter Norvig, © 2001 г.). Воспроизводится по разрешению. Оригинальную статью, включая гиперссылки, можно найти по адресу http://www.norvig.com/21-days.html. Мы включили ее, поскольку полагаем, что она содержит важную идею. Приведенная цитата является одной из наших давних любимых, и поскольку она применима к сути нашего приложения, мы ее также включили.

Почему каждый в такой спешке?

Зайдите в любой книжный магазин, и вы увидите «Научитесь Java за 7 дней» наряду с бесконечными вариациями, предлагающими научиться Visual Basic, Windows, Internet и т.д. за несколько дней или часов. Я произвел следующий расширенный поиск на Amazon.com:

pubdate: after 1992 and title: days and

(title: learn or title: teach yourself)

и получил 248 попаданий. Первые 78 были компьютерными книгами (номер 79 был «Изучите Бенгали за 30 дней»). Я заменил «дни» ('days') на «часы» ('hours') и получил замечательным образом сходные результаты: еще 253 книг, из них 77 компьютерных, за которыми следовала под номером 78 «Научитесь грамматике и стилистике за 24 часа». Всего из верхних 200 книг 96% были компьютерные.

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

Давайте проанализируем, что может означать название наподобие «Изучите Паскаль за три дня»:

• Изучите: за 3 дня у вас не будет времени написать несколько значительных программ и научиться из них на своих успехах и неудачах. У вас не будет времени поработать с опытным программистом и понять, на что похожа жизнь в этом окружении. Короче, у вас не будет времени научиться многому. Поэтому можно говорить лишь о поверхностном знакомстве, а не глубоком понимании. Как сказал римский папа Александр, неглубокое знание является опасной вещью.

• Паскаль: за 3 дня вы смогли бы изучить синтаксис Паскаля (если вы уже знаете сходный язык), но не смогли бы много узнать о том, как использовать этот синтаксис. Короче, если бы вы были программистом на Бейсике, вы смогли бы писать программы в стиле Бейсика на Паскале, но не смогли бы изучить, для чего Паскаль в действительности подходит (или не подходит). В чем же суть? Алан Перлис (Alan Perlis) сказал однажды: «Язык, который не влияет на способ вашего мышления о программировании, не стоит того, чтобы его знали». Другими словами, вам приходится изучить крошечный кусок Паскаля (или, более вероятно, чего-то наподобие Visual Basic или JavaScript), поскольку вам нужно взаимодействовать с существующим инструментом для выполнения определенной задачи. Но тогда вы не обучаетесь программированию; вы учитесь выполнять эту задачу.

• За три дня: к сожалению, этого недостаточно, как показывает следующий раздел.

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

Ученые (Hayes, Bloom) показали, что развитие высокой квалификации в любой из широкого разнообразия областей, включая шахматы, сочинение музыки, рисование, игра на фортепьяно, плавание, теннис, исследования в нейропсихологии и топологии, занимают около десяти лет. По-видимому, в действительности не может быть сокращения: даже Моцарту, который был музыкально одаренным уже в 4 года, потребовалось еще 13 лет, прежде чем он начал создавать мировую классическую музыку. В другом жанре Битлз, казалось, вырвались на сцену, появившись в шоу Эда Салливана в 1964 г. Но они играли с 1957 года, и хотя они рано завоевали широкую популярность, их первый переломный успех, Сержант Пепперс, был выпущен в 1967 г. Сэмюэл Джонсон (Samuel Johnson) считал, что требуется более десяти лет: «Мастерство в любой отрасли достигается лишь работой в течение жизни; его нельзя купить по меньшей цене». А Чосер (Chaucer) жаловался: «Жизнь так коротка, а ремеслу так долго учиться».

Вот мой рецепт для успеха в программировании:

• Заинтересуйтесь программированием и сделайте что-нибудь, потому что это забавно. Убедитесь, что оно продолжает оставаться достаточно интересным, чтобы вы хотели прилагать усилия в течение десяти лет.

• Говорите с другими программистами; читайте другие программы. Это важнее, чем любая книга или учебный курс.

• Программируйте. Лучшей разновидностью обучения является обучение деланием. Говоря более технически, «максимальный уровень производительности индивидуума в данной области не достигается автоматически как функция расширения опыта, но его могут повысить даже очень опытные индивидуумы в результате обдуманных усилий по совершенствованию» и «наиболее эффективное обучение требует хорошо определенной задачи с соответствующим уровнем трудности для данного конкретного индивидуума, информационной обратной связи и возможностей повторения и исправления ошибок». Книга Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life (Практическое познание мышление, математика и совершенствование способностей в повседневной жизни) является интересным справочным пособием для этой точки зрения.

• Если хотите, проведите четыре года в колледже (или еще больше в аспирантуре). Это даст вам доступ к некоторым видам работ, требующим диплома, и это даст более глубокое понимание области, но если вам не нравится школа, вы можете (с некоторым упорством) получить аналогичный опыт на работе В любом случае, одного лишь изучения книг недостаточно. «Образование в компьютерных науках может сделать кого-нибудь искусным программистом не в большей степени, чем изучение кистей и красок может сделать кого-то искусным художником», – говорит Эрик Реймонд (Eric Raymond), автор The New Hacker's Dictionary (Словаря новых хакеров). Один из лучших программистов, которых я когда-либо принимал на работу, имел лишь среднее образование, он создал массу превосходных программ, у него есть своя группа новостей и через фондовые опционы, без сомнения, намного богаче, чем буду я когда-либо.

• Работайте над проектами с другими программистами. Будьте лучшим программистом в некоторых проектах; будьте худшим в некоторых других. Когда вы лучший, вы принимаетесь проверять свои способности возглавлять проект и вдохновлять других своим видением. Когда вы худший, вы изучаете то, что делают мастера, и вы изучаете, что они не любят делать (поскольку они заставляют делать это за себя вас).

• Работайте над проектами после других программистов. Погрузитесь в понимание программы, написанной кем-то еще. Посмотрите, чего стоит понять и исправить ее, когда рядом нет авторов программы. Подумайте над тем, как спроектировать свои программы, чтобы сделать их проще для тех, кто будет их сопровождать после вас.

• Изучите по крайней мере полдюжины языков программирования. Включите один язык, поддерживающий абстракции классов (подобно Java или С++), один, поддерживающий функциональные абстракции (подобно Lisp или ML), один, поддерживающий синтаксические абстракции (подобно Lisp), один, поддерживающий декларативные спецификации (подобно Prolog или шаблонам C++), один, поддерживающий сопрограммы (подобно Icon или Scheme), и одни, поддерживающий параллелизм (подобно Sisal).

• Помните, что в «компьютерных науках» есть «компьютер». Знайте, сколько времени ваш компьютер тратит на исполнение инструкции, получение слова из памяти (с попаданием в кэш и без попадания), чтение последовательных слов с диска и поиск нового положения на диске (Ответы ниже.)

• Погрузитесь в работу по стандартизации языка. Это может быть комитет ANSI С++, или это может быть принятием решения, должен ли ваш местный стиль программирования использовать 2 или 4 пробела в отступах. В любом случае, вы узнаете, что любят в языке другие люди, насколько глубоко они это чувствуют и, возможно, даже немного о том, почему они это чувствуют.

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

Держа все это в уме, сомнительно, насколько далеко вы сможете уйти, обучаясь лишь по книгам. До рождения моего первого ребенка я прочел все книги How To (Как…), и до сих пор чувствую себя необразованным новичком. 30 месяцев спустя, когда ожидался мой второй ребенок, вернулся ли я к книгам, чтобы освежить их в памяти? Нет. Вместо этого я полагался на свой собственный опыт, который оказался для меня намного более полезным и обнадеживающим, чем тысячи страниц, написанных экспертами.

Фред Брукс (Fred Brooks) в своем эссе Никаких серебряных пуль (No Silver Bullets) определил план из трех частей для обнаружения великих проектировщиков программного обеспечения:

1. Систематически как можно раньше распознавать ведущих проектировщиков.

2. Назначить наставников по достижениям, ответственных за разработку перспективы и тщательно хранить архивы достижений.

3. Предоставлять растущим проектировщикам возможности для взаимодействия и стимулирования ими друг друга.

Это предполагает, что у некоторых людей уже есть качества, необходимые, чтобы стать великими проектировщиками; задача заключается в том, чтобы соответствующим образом их выманить. Алан Перлис (Alan Perlis) выразился более лаконично– «Каждого можно научить ваять: Микеланджело пришлось бы учить, как не делать это. Так же и с великими программистами».

Поэтому вперед, купите эту книгу по Java; возможно, вы получите от нее какую– нибудь пользу. Но вы не измените свою жизнь или свою действительную общую квалификацию как программиста за 24 часа, дня или даже месяцев.

Ссылки

Bloom, Benjamin (ed.) Developing Talent in Young People, Ballantine, 1985.

Brooks, Fred, No Silver Bullets, IEEE Computer, vol. 20, no 4, 1987, p. 10-19.

Hayes, John R., Complete Problem Solver, Lawrence Erlbaum, 1989.

Lave, Jean, Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life, Cambridge University Press, 1988.

Ответы

Время выполнения различных операций на типичном ПК 1 ГГц летом 2001 г.:

исполнение одной инструкции  1 нс = (1/1000 000 000) сек

выборка слова из кэша L1  2 нс

выборка слова из основной памяти  10 нс

выборка смежного слова с диска  200 нс

выборка слова из нового места на диске (поиск) 8 000 000 нс = 8 мс

Сноски

Эта страница[191]191
  Это приложение приведено в буквальном виде с веб-страницы, указанной вначале – Примеч. автора.


[Закрыть] доступна также в переводе на японский язык[192]192
  http://www1.neweb.ne.jp/wa/yamdas/column/technique/21-daysj.html – Примеч. автора.


[Закрыть] благодаря Yasushi Murakawa и в переводе на испанский язык[193]193
  http://loro.sf.net/notes/21-dias.html – Примеч. автора.


[Закрыть] благодаря Carlos Rueda.

T. Capey указывает, что страница Complete Problem Solver на Amazon теперь содержит книги Teach Yourself Bengali in 21 days и Teach Yourself Grammar and Style под рубрикой «Клиенты, которые купили эту книгу, купили также и эти книги». Я догадываюсь, что большая часть людей, посмотревших на ту книгу, пришли с этой страницы.

Приложение В
Лицензия Caldera для старой Unix[194]194
  Это – неофициальный перевод Лицензии Caldera для старой Unix на русский язык. Он не был опубликован Caldera International, Inc и не может легально определять условия распространения программных продуктов, использующих Лицензию Caldera – только оригинальный английский текст Лицензии Caldera для старой Unix имеет законную силу.


[Закрыть]

CALDERA

240 West Center Street

Orem, Utah 84057

801-765-4999 Fax 801-765-4481

23 января 2002 г.

Дорогие энтузиасты UNIX®,

Caldera International, Inc. настоящим предоставляет безвозмездную лицензию, которая включает права на использование, модификацию и распространение этого названного исходного кода, включая создание производных двоичных изделий из исходного кода. Исходный код, для которого Caldera International, Inc. передает права, ограничены следующими операционными системами UNIX, которые работают на 16-разрядном процессоре PDP-11 и ранних версиях 32-разрядной операционной системы UNIX, со специальным исключением UNIX System III и UNIX System V и операционных систем-наследников:

32-разрядной 32V UNIX,

16-разрядной UNIX версий 1, 2, 3, 4, 5, 6, 7.

Caldera International, Inc. не дает никаких гарантий или поручительств, что какой-нибудь исходный код доступен от Caldera International, Inc.

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

Copyright © Caldera International Inc. 2001–2002. Все права сохранены. Разрешается распространение и использование в исходной и двоичной форме, с модификациями или без них, при соблюдении следующих условий:

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

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

Этот продукт включает программное обеспечение, разработанное или принадлежащее Caldera International, Inc.

Ни название Caldera International, Inc., ни названия других внесших вклад участников не могут использоваться для поддержки или продвижения продуктов, производных отданного программного обеспечения, без особого предварительного письменного разрешения.

ИСПОЛЬЗОВАНИЕ ЭТОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ПРЕДУСМОТРЕНО ПО ЛИЦЕНЗИИ CALDERA INTERNATIONAL, INC. И ДРУГИХ ВНЕСШИХ ВКЛАД УЧАСТНИКОВ «КАК ЕСТЬ» И БЕЗ ВСЯКИХ ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ, ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯСЬ НЕЯВНЫМИ ГАРАНТИЯМИ ПРИГОДНОСТИ ДЛЯ ПРОДАЖИ ИЛИ ПРИМЕНИМОСТИ ДЛЯ ОПРЕДЕЛЕННЫХ ЦЕЛЕЙ. НИ В КОЕМ СЛУЧАЕ CALDERA INTERNATIONAL, INC. НЕ НЕСЕТ ОТВЕТСТВЕННОСТИ ЗА ЛЮБОЙ ПРЯМОЙ, КОСВЕННЫЙ, СЛУЧАЙНЫЙ, СПЕЦИАЛЬНЫЙ, ШТРАФНОЙ ИЛИ ЯВЛЯЮЩИЙСЯ СЛЕДСТВИЕМ УЩЕРБ (ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯСЬ ПРИОБРЕТЕНИЕМ ИЛИ ЗАМЕНОЙ ТОВАРОВ; ПОТЕРЮ ЦЕННОСТИ, ДАННЫХ, УПУЩЕННУЮ ВЫГОДУ ИЛИ ПРИОСТАНОВКУ БИЗНЕСА), КАК БЫ ОН НИ БЫЛ ВЫЗВАН И В СООТВЕТСТВИИ С КАКИМИ БЫ ТО НИ БЫЛО ПРЕДПОЛОЖЕНИЯМИ, БУДЬ ТО В КОНТРАКТЕ, НЕПОСРЕДСТВЕННОЙ ОТВЕТСТВЕННОСТИ ИЛИ ГРАЖДАНСКОМ ПРАВОНАРУШЕНИИ (ВКЛЮЧАЯ НЕБРЕЖНОСТЬ ИЛИ ДРУГОЕ), ВОЗНИКШИЕ ЛЮБЫМ СПОСОБОМ ВСЛЕДСТВИЕ ИСПОЛЬЗОВАНИЯ ДАННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, ДАЖЕ В СЛУЧАЕ ПРЕДУПРЕЖДЕНИЯ О ВОЗМОЖНОСТИ ТАКОГО УЩЕРБА.

Искренне ваш,

(подпись) Bill Broderick

Bill Broderick

Директор, Служба лицензирования

UNIX является зарегистрированной торговой маркой Open Group в США и других странах.