Содержание

• Увертюра
• Корень сайта и "Мои документы"
• CGI, Perl, как все запущено

Увертюра

Только ленивый интернетчик сейчас не занимается cайтостроительством, по крайней мере собственного, что назыается, хомяка. Очень хорошо для такой цели соорудить "локальный верстак" на рабочем ПК, который бы максимально копировал окружение хостинг-провайдера. Вот тут и начинают возникать проблемы. У хостинг провайдера обычно установлен какой-нибудь из UNIX-клонов, а на любимой персоналке или ноутбуке - какой-нибудь из клонов Windows. К счастью, большинство программного обеспечения, используемого для организации WWW хостинга на UNIX-подобных системах, портировано и на платформу win32, и это позволяет соорудить стенд почти полостью повторяющий целевое окружение. К несчастью, это "порченное" программое обеспечение порой ведет себя не совсем так, как ожидается, в окружении ему чуждом. WWW сервер Apache здесь не исключение...

Корень сайта и "Мои документы"

Ну не нравится мне организация катлогов в Windows, не нравится потому, что привык к другой, с моей точки зрения более логичной, но не об том сейчас речь. Система навязывает определенные правила размещения, с которыми все же приходится соглашаться, хочешь - не хочешь, по многим причинам. От того и разместить данные сайта представляется наиболее логичным внутри каталога "Мои документы". Но, не тут-то было! Грабли кодировок, положенные давным-давно в ОС Windows, больно бьют и здесь. Простое указание корня сайта в конфигурации Apache эффекта не дает - Apache его не находит и от того не работает.

DocumentRoot "C:/Documents and Settings/vap/Мои документы/sites/vap.org.ru/htdocs/"

Проблема в том, что путь внутри себя содержит русские буквы, которые непонятно как интерпретируются Apache и Windows. Решение, как оказалось, тривиально - необходимо просто сохранить конфигурационный файл Apache в кодировке UTF-8.

Вообще говоря, давно уже пора забыть про всякие там koi8-r, cp1251 и иже с ними, а ровно как и войны с ними связанные. Повсеместное применение UTF-8, в том числе в HTML документах, позволяет избежать многих проблем с совместимостью, избежать необходимости в перекодировках, тем самым сделать жизнь проще.

CGI, Perl, как все запущено

Многие видели в начале CGI Perl скриптов строчку вида:

#!/usr/bin/perl -wT

Она имеет смысл в unix-подобных ОС, где инструктирует интерпретатор командной строки как запускать данный скрипт, строка фактически указывает путь запуска интерпретатора языка скрипта и необходимые аргументы коммандной строки для запуска, если они нужны. Windows эту информацию не использует, оно оперирует расширением имени файла для того чтобы определить как данный файл обрабатывать - наследие MS-DOS. Поэтому все скрипты запущенные из коммандной строки Windows работают вне зависимости от того, что в строке запуска интерпретатора написано, или вообще ничего - лишь бы расширение файла было правильным. Однако, Apache, запуская CGI приложение, имеет на этот счет свое мнение - оно интерпретирует эту строку по всем правилам, что создает серьезную проблему.

Проблема в том, что интерпретатор скриптового языка в Windows, как впрочем и вся сопутствующая требуха, устанавливается в совершенно другие каталоги, имеющие совершенно другую организацию. Зачем так было сделано - вопрос к тем, кто это придумал. С этим приходится мириться и как-то из этого выкручиваться.

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

#!c:/Perl/bin/perl.exe

Это решает проблему на месте, но создает другую более серьезную проблему с установкой скриптов на целевую платформу. Там-то пути доступа к интерпретаторам совершенно другие! Поэтому, добившись локальной работоспособности, мы все сломаем на боевом сайте. Модифицировать строки интерпретатора во всех скриптах при размещении их на сайте - задача безрадостная, особенно когда скриптов много. Написать дополнительный скрипт, который такую модификацию автоматизирует - костыль, борьба с последствиями вместо устранения причины проблемы.

Можно попытаться сохранить строки в соответствии с требованиями целевой платформы, подложив на локальной платформе исполняемые модули по ожидаемым путям. Однако, и это решение не блещет. Во-первых, мы тем самым захламляем нашу локальную файловую систему. Во-вторых, такая подстановка не всегда возможна из-за, хотя бы, того, что пакеты могут размещаться на разных дисковых устройствах - опять же MS-DOS наследие. В-третьих, это усложнает обновление локальных пакетов - придется помнить, что вновь установленные модули нужно вручную скопировать еще куда-то. В-четвертых... Нафиг!!!

Делать же нужно вот что. Разработчики Apache, на самом деле и к счастью, учли такую проблему и продумали способ ее решения. Существует специальная конфигурационная директива ScriptInterpreterSource которую необходимо добавить в глобальную конфигурацию сервера, конфигурацию виртуального сайта, или описатель каталога:

ScriptInterpreterSource Registry-Strict

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

HKEY_CLASSES_ROOT\.pl\Shell\ExecCGI\Command\(Default) => C:\Perl\bin\perl.exe -wT

Ну и, естественно, на месте C:\Perl\bin\perl.exe должен стоять правильный путь к вашему установленному Perl интерпретатору.