Возможно, в имя файла вашего сценария понадобится вводить определенное расширение, например eg/илир1. Мы возражаем против подобной настройки WWW-сервера, предпочитая устанавливать разрешение на выполнение CGI для каждого каталога отдельно, но в некоторых конфигурациях она может быть необходима. Автоматически позволять, чтобы все заканчиваюшиеся на .cgi файлы были исполняемыми, рискованно, если FTP-клцентам разрешается производить запись во всех каталогах, а также при "зеркальном" копировании чужой структуры каталогов. В обоих случаях выполняемые программы могут внезапно появиться у вас на сервере без ведома и разрешения Web-мастера. Это означает также, что все файлы, имена которых имеют расширение cgi или р1, нельзя будет вызывать через обычный URL. Данный эффект может иметь самые разные последствия - от нежелательных до катастрофических.

Помните: расширение р1 означает, что это Perl-библиотека, а не исполняемый Perl-файл. Не путайте эти понятия, иначе вашей судьбе не позавидуешь. Если у вас безусловно должно быть уникальное расширение для разрешения выполнения Perl-программ (потому что ваша операционная система просто не настольно умна, чтобы использовать нечто вроде записи # ! /usr/bin/perl), мы предлагаем использовать расширение р1х. Это, однако, не избавит вас от других только что упомянутых нами проблем.

Конфигурация вашего сервера требует особого разрешения на выполнение CGI для каталога, в который вы поместили свой CGI-сценарий. Убедитесь в том, что разрешены и GET, и POST. (Ваш Web-мастер знает, что это значит.)

Web-сервер не выполняет ваш сценарий при запуске с вашим идентификатором пользователя. Убедитесь в том, что файлы и каталоги, к которым обращается сценарий, открыты для всех пользователей, для которых Web-сервер выполняет сценарии, таких как, например, nobody, wwwuser или httpd. Возможно, вам понадобится заранее создать такие файлы и каталоги и присвоить им самые широкие права доступа для записи. При работе в среде UNIX это делается посредством команды chmod a+w. Предоставляя широкий доступ к файлам, всегда будьте настороже.

Всегда запускайте свой сценарий с Perl-флагом -w, чтобы иметь возможность получать предупреждения. Они направляются в файл регистрации ошибок Web-сервера, который содержит сообщения об ошибках и предупреждения, выдаваемые вашим сценарием. Узнайте у своего Web-мастера путь к этому файлу и проверяйте его на предмет наличия проблем. О том, как лучше обрабатывать ошибки, можно узнать и из описания стандартного модуля ССТСаф.

Убедитесь, что версии программ и пути к каталогам с Perl и всем используемым вами библиотекам (вроде CGI.pm) на компьютере, где работает Web-сервер, соответствуют ожидаемым.

• в начале своего сценария включите режим autoflush для дескриптора файла STDOUT, присвоив переменной $ значение "истина", например 1. Если вы применили модуль FileHandle или любой из модулей ввода-вывода (скажем, IO::File, lOi.Socket и т.д.), то можете использовать с этим дескриптором файла метод, имя которого легко запомнить: autoflush {) :

use FileHandle; STDOUT->autoflush(1) ;

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

Perl и Web: не только CGI-программирование

Perl используется не только в CGI-программировании. Среди других направлений его применения - анализ файлов регистрации, управление встроенными функциями и паролями, "активными" изображениями, манипулирование изображениями*. И все это - лищь верхущка айсберга.

Специализированные издательские системы

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

Perl - идеальный язык для создания специализированных издательских систем, приспособленных под ваши уникальные потребности. С его помощью можно одним махом преобразовать необработанные данные в мириады HTML-страниц. Perl применяется для формирования и сопровождения узлов по всей World Wide Web. The Perl Journal (www.tpj.com) использует Perl для создания всех своих страниц. Perl Language Home Page {www.perl.com) содержит около 10000 Web-страниц, которые автоматически сопровождаются и обновляются различными Perl-программами.

Perl-интерфейс к графической библиотеке gd Томаса Баутелла содержится в модуле GD.pm, который можно найти в CPAN.

Встроенный Perl

Самый быстрый, самый дешевый (дешевле бесплатного уже ничего быть не может) и самый популярный Web-сервер в Internet, Apache, может работать с встроенным в него Perl, используя модуль mod perl из CPAN. С этим модулем Perl становится языком программирования для вашего Web-сервера. Вы можете писать маленькие Peri-программы для обработки запросов проверки полномочий, обработки сообщений об ошибках, проведения регистрации и решения любых других задач. Они не требуют запуска нового процесса, потому что Perl теперь встроен в Web-сервер. Еще более привлекателен для многих тот факт, что при работе с Apache вам не нужно запускать новый процесс всякий раз, когда поступает CGI-запрос. Вместо этого создается новый поток, который и выполняет предкомпилированную Peri-тфограмму. Это значительно ускоряет выполнение ваших CGI-программ; обычно работа замедляется из-за вызовов fork/exec, а не из-за большого объема самой программы.

Другой способ ускорить выполнение CGI - использовать стандартный модуль CGI::Fast. В отличие от описанного выше встроенного интерпретатора Perl, такая схема выполнения CGI не требует наличия Web-сервера Apache. Подробности см. на тап-странице модуля CGI::Fast.

Если Web-сервер у вас работает под Windows NT, вам определенно следует посетить Web-сервер ActiveWare, www.activeware.com. Там можно найти не только готовые двоичные файлы Peri для Windows-платформ*, но и PeriScript и Perils. Пакет PeriScript - это механизм разработки сценариев ActiveX, который позволяет встраивать Peri-код в ваши Web-страницы так, как это делается средствами JavaScript и VBScript. Пакет PerllS - это динамически связываемая библиотека интерфейса ISAPI, которая выполняет Peri-сценарии непосредственно из IIS и других ISAPI-совместимых Web-серверов, давая значительный выигрыш в производительности.

Автоматизация работы в Web с помощью LWP

Ставили ли вы когда-нибудь перед собой задачу проверить Web-документ на предмет наличия "мертвых" ссылок, найти его название или выяснить, какие из его ссылок обновлялись с прошлого четверга? Может быть, вы хотели загрузить изображения, которые содержатся в каком-либо документе, или зеркально скопировать целый каталог? Что будет, если вам придется проходить через proxy-сервер или проводить переадресацию?

Стандартный дистрибутив Perl версии 5.004 предусматривает инсталляцию под Windows, при этом предполагается, что у вас есть компилятор С (и это предположение, как правило, оправдывается).