[devel] awk in initscripts

[Andrey Orlov]

Поскольку в качестве примера неудачного решения использовали конфиги 
экземпляров zope....

On Monday 12 January 2004 01:26, Peter V. Saveliev wrote:
> Хочется услышать возможные возражения против использования awk в
> инитскриптах прежде, чем я возьмусь это делать.

> 2) можно без нужды не плодить директории в /etc/sysconfig. как это сейчас:
> для каждой сессии того же vtund пришлось сделать свой файлик на манер
> конфига экземпляра zope. Субъективно бесит, ей-Аллаху.

Я не против использования awk для обработки конфигов,
но я против того, что бы использовать его для того, чбы слить
все конфиги в один файл, как это можно было бы сделать с 
экземплярами Zope: так как такой подход как

devel.path = ...
devel.port = 8080

hosting.path = ...
hosting.port = 8180

Равно как и такой:

[devel]
path = ..
port = 8080

[hosting]
path = ...
port = 8180

Объективно бесит, хотя с помощьюе awk реализовать их
разбор можно достаточно легко.

И так, почему конфиги экземпляров Zope лежат в отдельных
файлах:

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

2. Если файл одного из экземпляров будет испорчен неверным
синаксисом (например, файл devel)
то остальные экземпляры останутся работоспособны;

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

4. Создание нового экземпляра на основе старого делается командой cp ;),
что тоже удобно.

5. Возможно пакетирование экземляров Zope  в rpm и т.п.

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

Субъективно, мое мнение, ситуацию с конфигами можно развивать
в одном из двух направлений:

1. Создать единый реестр, аналогичный win32;

2. Максимально гранулировать текущие конфигурационные файлы;

И в другом случае потребуется создание специальных средств: диспетчера
реестра (1) или специальной файловой системы (2). Традиционно, последние
неск лет, развитие линукс идет по 2-му пути. Можно попытатся спорить
об их эффективности, но спор этот бессмысленен, т.к. в дальней перспективе
оба пути сходятся (функционально) к одному и тому же решению. В то же время,
с точки зрения такой опции, как управления правами к конфигам, 2ой путь в случае
линукс намного более приемлем.

Наконец, довод против awk: если уж делать единый конфиг (не важно, для Zope, для network
или еще для чего) то не смотря на всю мою любовь к awk ;), есть продвинутые процессоры
для генерации парсеров их и стоит использовать: составить язык конфигурационных
файлов и парсить его. AWK - для обработки логов и т.п. работы, где он очень сильно на
своем месте, в отличие от применения в качестве синтаксического процессора.

ЗЫ: Опять же как довод против слияения в один файл - традиционно, последние
несколько лет, одно из самых распространенных предложений: "давайте для файла
что-то-там.conf создадим каталог что-то-там.d", и создают.

ЗЗЫ2all: Кстати, мбть пропатчить в этом направлении httpd ? Можно было бы
устанавливать новые пакеты и активировать подсистемы без извратов на основе
sed, которые, кстати, не всегда работают....

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray на neural.ru, jid: cray на altlinux.org ---
----------------------------------------