Читать онлайн «Linux программирование в примерах». Страница 156

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.

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

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

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]

Эта классическая книга по программированию на Unix, описывающая целостную структуру окружения Unix, от интерактивного использования до программирования оболочки, программирования с помощью функций <stdio.h> и низкоуровневых системных вызовов, разработки программ с помощью 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. Хотя мы не всегда согласны со многим из того, что хочет сказать автор, книга действительно содержит значительное количество важного материала, и ее стоит прочесть.

Данная глава написана Петером Норвигом (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), поскольку вам нужно взаимодействовать с существующим инструментом для выполнения определенной задачи. Но тогда вы не обучаетесь программированию; вы учитесь выполнять эту задачу.