8.16. Чтение конфигурационных файлов

Проблема

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

Решение

Организуйте обработку файла в тривиальном формате ПЕРЕМЕННАЯ=ЗНАЧЕНИЕ, создавая для каждого параметра элемент хэша «ключ/значение»;

while (<C0NF1G>) {

chomp, # Убрать перевод строки

s/#.. , и Убрать комментарии

s/~\s+ ; # Убрать начальные пропуски

s/\s+$ ; и Убрать конечные пропуски

next unless length; # Что-нибудь осталось my ($var, Svalue) = split(/\s.=\s./, $ , 2); $User Preferences{$var) = Svalue;

Существует другой более изящный вариант - интерпретировать конфигурационный файл как полноценный код Perl;

do SENViHDME}/ progrc ,

Комментарий

в первом решении конфигурационный файл интерпретируется в тривиальном формате следующего вида (допускаются комментарии и пустые строки):

# Сеть класса С NETMASK = 255.255 255 О МТи = 296

DEVICE = cua1 RATE = 115200 MODE = adaptive

После этого можно легко получить значение нужных параметров - например, $User P references {"RATE"} дает значение 115200. Если вы хотите, чтобы конфигурационный файл непосредственно устанавливал значения переменных в программе вместо заполнения хэша, включите в программу следующий фрагмент:

по strict refs; SSvar = Svalue;

и переменная $RATE будет содержать значение 115200.

Во втором решении do организует непосредственное выполнение кода Perl. Если вместо блока используется выражение, do интерпретирует его как имя файла. Это практически идентично применению require, но без риска фатальных

8.16. Чтение конфигурационных файлов 315

исключений. В формате второго решения конфигурационный файл принимает следующий вид:

# Сеть класса С

SNETMASK = 255.255.255 О;

$МТи = 0x128;

$DEVICE = сиаГ,

$RATE = 115 200;

$M0DE = adaptive;

Если вам непонятно, зачем включать в файл лишние знаки препинания, задумайтесь - в вашем распоряжении оказывается весь синтаксис Perl. Теперь простые присваивания можно дополнить логикой и проверкой условий:

If (SDEVICE =- /1$/) {

SPATE = 28 800, } else {

$RATE = 115 200,

Bo многих программах предусмотрены системные и личные конфигурационные файлы. Если вы хотите, чтобы предпочтения пользователя отменяли действия системных параметров, загрузите личный файл после системного:

SAPPDFLT = "/usr/local/share/myprog ,

do "SAPPDFLT/sysconfig.pl, do "$ENV{HOME}/.myprogrc";

Если при существующем личном файле системный файл должен игнорироваться, проверьте возвращаемое значение do:

do SAPPDFLT/sysconfig. рГ or

do $ENV{HOME}/.myprogrc;

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

{ package Settings; do "$ENV{H0ME}/ myprogrc" }

Файл, прочитанный с помощью do (а также require и use), представляет собой отдельную, самостоятельную область действия. Это означает как то, что конфигурационный файл не может обратиться к лексическим (ту) переменным вызывающей стороны, так и то, что вызывающая сторона не сможет найти такие переменные, заданные в файле. Кроме того, пользовательский код не подчиняется директивам типа use strict или use integer, способным воздействовать на вызывающую сторону.

Если столь четкое разграничение видимости переменных нежелательно, вы можете заставить код конфигурационного файла выполняться в вашей лексической области действия. Имея под рукой программу cat или ее эквивалент, можно написать доморощенный аналог do:

eval cat $ENV{HOME}/.myprogrc;

Мы еще не видели, чтобы кто-нибудь (кроме Ларри) использовал такой подход в рабочем коде.

Во-первых, do проще вводится. Кроме того, do учитывает @INC, который обычно просматривается при отсутствии полностью указанного пути, но в отличие от require в do не выполняется неявная проверка ошибок. Следовательно, вам пе придется заворачивать do в eval для перехвата исключений, от которых ваша программа может скончаться, поскольку do уже работает как eval.

При желании можно организовать собственную проверку ошибок:

$file = "someprog.pi"; unless (Sreturn = do Sfile) {

warn "couldnt parse $file: $@" if $@;

warn "couldnt do $file: $!" unless defined Sreturn;

warn "couldnt run Sfile" unless Sreturn;

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

Однако не следует забывать о безопасности. Как убедиться в том, что фа11л не модифицировался никем, кроме пользователя? Традиционный подход - не делать ничего, полагаясь исключительно на права доступа каталогов и файлов. В девяти случаях из десяти такое решение оказывается правильпы.м, поскольку большинство проектов попросту не оправдывает подобной паранойи. А если все же оправдывает, загляните в следующий рецепт.

1> Смотри также--

Описание функций eval и require вperlfunc(l); рецепты 8.17; 10.12.

8.17. Проверка достоверности файла

Проблема

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

Решение

Получите данные о владельце и правах доступа с помощью функции stat. Можно воспользоваться встроенной версией, которая возвращает список: