Вышел parse_conf 1.0pre

Что особенно хотелось бы обсудить (и что можно вполне еще поменять), это систему ссылок. Ссылки могут быть локальные и нелокальные. Локальные ссылки разрешаются так: сначала значения ищутся в той же секции, и если не находятся, то среди глобальных значений (любые значения до первой секции). Нелокальные прямо указывают секцию где искать. Виды ссылок

Локальные:

$x

$(x)

%(x)s

Глобальные:

$x@section

$(x)@section

$x@[section]

$(x)@[section]

Скобки нужны, когда имя переменной или секции содержит пробелы.

Однако, может лучше другая система. Изменить очень легко, меняется только сканнер для строк. Но лучше это решить раньше чем позже. Альтернатива может быть

$(section.name) или %(section.name)s

Неудобство этой системы в том, что тогда точка не может быть в имени переменной или секции. Может кто еще что-то придумает или предложит из других источников?

INI Ъ.

// кастую в тред geek-a

Может быть, > или ::? Вроде, достаточно редко используются.

Ещё чуть-чуть, и из этой либы получится tcl-интерпретатор :)

А XML оно умеет? ;)

ЗЫ. конфиг должен быть таким, чтобы любой лемминг мог его сам отредактировать. А если туда напихать кучу ссылок и прочей муры - программист сам себе создает головняк. И как правило посылается на йух вместе со своим поделием (потому что он один способен его быстро настроить)

> А XML оно умеет?

Нет и не будет.

> конфиг должен быть таким, 
> чтобы любой лемминг мог его сам отредактировать.

А что сложного в таком конфиге, (назовем его erunda.ini) например:

   usr dir = /home/bubukin/usr

   [ dirs ]

     bin = $(usr dir)/bin
     include = $(usr dir)/include
     lib = $(usr dir)/lib

Потом, чтобы получить, скажем директорию из bin, 
надо сделать следующее:

#include <parse_conf.h>

/... skipped .../

    pcnf_t pcnf = pcnf_alloc();

    pcnf_read( pcnf, "erunda.ini" );
    char *biddir = pcnf_sget( pcnf, "dirs", "bin");

Это трудно для леммингов отредактировать и использовать?
Бедные лемминги тогда.

> Может быть, > или ::? Вроде, достаточно редко используются.

Мне не очень нравится. :: конечно отчень сиплюсплюсно, но выглядит не очень, да и есть любители пользовать доветочие в именах групп.

Мне нравится еще такой вариант: $[имя группы]varname, или $([group]var). Но не знаю. Можно еще так: $[group](name) для общего случая и переменная без скобок, когда нет пробелов. Как думаете? Что бы было удобнее всего?

> Ещё чуть-чуть, и из этой либы получится tcl-интерпретатор :)

Был был большой соблазн сунуть еще туда условия типа GNU Make. Но искушение было преодолено.

Во, спасибо, попользуемся, а то я обычно свои костыли леплю для парсинга конфигов >_>

Я бы исключил возможность применять пробелы в имени переменной. Тогда и необходимость в скобках отпала бы.

Глобальные лучше через точку указывать: $section.name.

Локальные пусть будут с процента начинаться, %name - отличать от глобальных проще.

Хотя пожалуй без скобок не обойтись.

Пусть будет так:

$(section.name) - глобальные,
%(name) - локальные.

> $(section.name)

или

$section.name

Пробелы в именах -- Зло. Визуально определить количество пробелов или знаков табуляции достаточно утомительно.

LETTER: 'A'..'Z' | 'a'..'z' | '0'..'9' ;

SECTION_NAME: LETTER+ ('_' LETTER)* ;

PARAMETER_NAME: LETTER+ ('_' LETTER)* ;

LINK: '$' (SECTION_NAME '.')? PARAMETER_NAME ;

Самый логичный вариант.

> Неудобство этой системы в том, что тогда точка не может быть в имени переменной или секции.

Пунктуация (как в прочем и пробелы) служит для разделения текста, и не входит в состав слов. Зачем усложнять простые вещи?

Кастую спор на 10 страниц: XML vs ini vs Plain text vs binary.

Ткните носом: как получить список всех секций?

>Кастую спор на 10 страниц: XML vs ini vs Plain text vs binary.

XML vs ini vs Plain text

Однозначно победил Plain text, особенно если учитывать, что в это понятие входят xml и ini.

Двоичные конфиги засунь себе в шестнадцатеричный редактор.

Количество свободных парсеров конфигов неуклонно приближается к числу свободных проектов?

Мало что ли этих парсеров? Нет, как 15 лет назад пишем свои новые, революционные велосипеды, дублирующие функциональность.

Где эти парсеры? Я, когда искал, не был сражен числом.

Честно говоря, не понял что там такого кроме парсера, сгенерированного с помощью Бизона. Но вызывает гордость то, что документация написана на приличном английском. Обычно, читая документацию моих соотечественников, становится обидно за державу... ;)

> Где эти парсеры? Я, когда искал, не был сражен числом.

Идём на sf.net, вводим в поиске "config parser"

Searching projects gives 1462 results

Мало?

>Нет и не будет.

это просто "flood mode" был :)

а вот бедные не лемминги, а программеры/саппорт которым надо пояснять по телефону этим дебилам что и где поправить...

$(section).$(name) совсем хороший вариант будет ;)

>$(section).$(name) совсем хороший вариант будет ;)

Мне не нравится, это похоже на две переменные между которыми находится точка. Лучше - $(section.name)

Зачем оно нужно, когда есть куча xml-парсоров и libconfig на худой конец?

Прошу прощения конечно, но ИМХО количество не значит качество. Вы вообще смотрели внимательно что именно этот поиск выдал? Вы сами таким образом что-то там нашли и удачно используете?

> Прошу прощения конечно, но ИМХО количество не значит качество. Вы вообще смотрели внимательно что именно этот поиск выдал? Вы сами таким образом что-то там нашли и удачно используете?

Я к тому и говорю, что чем плодить ещё yust another one config parser лучше обратить свои взоры на существующие проекты и потратить силы на их доработку, в случае необходимости.

З.Ы. использую libconfuse, xml парсилки, нативные для Erlang варианты загрузки конфигов кодом.

Удобно. Считаю - если кому-то нужно, пусть будет.

Вопрос - а xml поддерживает ссылки на переменные по типу сабжа?

То есть чтоб написать что-то типа

<mainPath>/usr/local/myProject</mainPath>
<htmlPath>$mainPath/public_html</htmlPath>

?

Я когда конфиг создавал, делал так:

<mainPath>/usr/local/myProject</mainPath>
<htmlPath relative="yes">public_html</htmlPath>

Ну и в разборщике конфига уже смотрел, если есть аттрибут relative, то добавлял mainPath. Можно немного модифицировать, конечно, и добавить аттрибут linkvar,например, так

<mainPath>/usr/local/myProject</mainPath>
<htmlPath linkvar="mainPath">$mainPath/public_html</htmlPath>

И в программе опять же менять mainPath на нужное значение. Но опять не идеально и всё делается руками в программе, а не средствами модели dom, а в сабже у автора автоматизировано, что етсь очень удобно.

Вопрос к знатокам xml - можно ли в xml использовать "переменные"?

ЗЫ. кастую в тред гика.

> Я к тому и говорю, что чем плодить ещё yust another one config parser лучше обратить свои взоры на существующие проекты и потратить силы на их доработку, в случае необходимости.

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

> З.Ы. использую libconfuse, xml парсилки, нативные для Erlang варианты загрузки конфигов кодом.

Сразу уточню, что я говорю о парсилке конфигов на С/C++ и не XML. Как я понимаю самое нормальное сейчас это libconfuse, возможно его и стоит развивать, если конечно с автором во вкусах сойтись :)

По теме может кто-то знает парсилку конфигов в апаческом стиле? Я в свое время полюбил соответствующий перловый модуль Config::General, но что-то не смог найти похожее для С/C++, а для Java проще было XML заюзать, хотя сначала тоже похожее поискал. Объявленный здесь модуль все же не то, хотя в закладки на всякий случай занес.

Полностью согласен ! Никто в сторону тикля не смотрит а жаль. Я немного процедур туда накидал и сейчас named.conf у меня парсится как tcl-скрипт.

Еще один велосипед. Теперь с третьим квадратным колесом. Когда автору надоест играться, закопайте.

Следующий шаг - сделать ЭТО бэкэндом для gconf? :)

>Eще один велосипед. Теперь с третьим квадратным колесом. Когда автору надоест играться, закопайте.

"Я буду долго гнать велосипед" (с) Николай Рубцов

> Следующий шаг - сделать ЭТО бэкэндом для gconf? :)

Отличная идея :). И к ConfigParser сделайте, а то он разрешает секции только с начала строки определять, сцуко. И переменные, определенные ниже, не хочет разрешать.

Всем высказавшимся по поводу вида ссылок ОГРОМНОЕ спасибо. Реализую очень быстро, как только определюсь. Мне самом текущая система не очень нравится, особенно из-за пристуствия лишнего знака @

> Я к тому и говорю, что чем плодить ещё yust another one config parser лучше обратить свои взоры на существующие проекты и потратить силы на их доработку, в случае необходимости.

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

Еще раз скажу: проект живет с 2002 года и с 2004 - живет нормальной жизнью. Если бы тогда что-то было под LGPL или GPL, я бы в жизнь не начал писать свой собственный.

Вариация закона Паркинсона: Каждый, освоивший хоть один язык программирования, обязательно напишет свой парсер конфигов.

Следствие из закона: число парсеров конфигов превышает число программистов

;)

В общем, мне кажется теперь, что предыдущие ссылки не очень хороши, так как (1) выглядят как-то не очень красиво (2) используют лишние знаки.

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

1. $[group](name) и сокращенные его варианты: $[group]name, $(name), $name. Достоинство очевидно: ничего лишнего в списке символов, лаконично и ини-файл понятен без дополнительных объяснений. И минимум ограничений на имена, а значит максимальная область допустимых значений конфигурационных файлов.

2. $(group.name), $group.name, $(name), $name. Недостаток - наличие лишнего символа (точки) в списке специальных символов. Квадратные скобки туда входят по определению, например. И как сдествие невозможность использовать точку в названии групп и переменных.

Достоинство - схожесть с C/Python/C++ и другими.

3. Оставить как сейчас. Достоинство - ничего не надо делать и "совместимость". Последнее не очень пока важно, ибо появилась такая возможность совсем недавно.

> Ткните носом: как получить список всех секций?

По человечески - никак пока. Я почему-то не учел этой возможности. А какой список было бы удобнее всего? Я имею в виду тип данных?

Сейчас можно только очень грубо, с использованием знания того, что такое тип pcnf_t и список ABL.

Чем оно лучше libconfig?

> Чем оно лучше libconfig?

Читаем в его документации первый же параграф и отвечаем:

1.1 Why Another Configuration File Library?

There are several open-source configuration file libraries available as of this writing. This library was written because each of those libraries falls short in one or more ways. The main features of libconfig that set it apart from the other libraries are:

* A fully reentrant parser. Independent configurations can be parsed in concurrent threads at the same time.

В parse_conf конечно же тоже "fully reentrant parser", точнее parsers.

* Both C and C++ bindings, as well as hooks to allow for the creation of wrappers in other languages.

Ну, на счет других хуков не скажу, но сделать wrapper к питону, например, ничем не труднее.

* A simple, structured configuration file format that is more readable and compact than XML and more flexible than the obsolete but prevalent Windows “INI” file format.

Ну, кто-то должен читать ини-файлы.

* A low-footprint implementation (just 38K for the C library and 66K for the C++ library) that is suitable for memory-constrained systems.

Ну, тут libconfig вне конкуренции, можно поджаться с установками gcc, но не до 38К.

* Proper documentation.

parse_conf имеет ничем не хуже доки. Да еще можно для программиста сгенерить дополнительные доки Доксидженом.

И наконец: libconfig не умеет разрешать ссылки.

Уныние и yet another config file format. Никто не заботится.

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

А к такой системе трансляторы в классические текстовые конфиги разных синтаксисов. Т.е. есть /conf/net/resolving/nameservers/0 с содержимым "10.0.0.1" и оно превращается в "nameserver 10.0.0.1" в /etc/resolv.conf. И так или свой etc (etcfs) или туды-сюды гоняется...

А если еще можно /conf/net/resolving/nameservers прочитать еще и как файл и там получить plain text по строчке на IP сервера... Было бы просто отлично.

Помойка /etc и ~/.* получила бы новую жизнь. В нормальном виде. Исключения, когда когфиг реально сложен, а то и вообще является Тьюринг-полным, оставляем отдельно — на то это и исключения — а большинство же конфигов этого никак не требует и способно обойтись чуть ли не классическими .ini.

Вот что, наверное, надо делать, а не еще один синтаксис для конфигов. По крайней мере это было бы ново (если не считать что все, как обычно, идет к нам из мертвых, но вечно живых Hurd и Plan 9) и архитектурно интересно.

P.S. In before Windows Registry — реестр уныл только потому что мало кто читал гайдлайны как куда ложить, в силу того что все летит непойми от кого (как правило Администратора и LOCAL SERVICE, ага) не применяются полноценные пермишшены, нет нормальных неймспейсов, нет системы типов (string, integer, binary и, вроде, и все, как я смутно помню венду?) и оно совершенно отдельно от всего, а не органично вписано в виде части файловой системы. В самой же идее иерархической системы с данными ничего плохого нет, вон, procfs отлично работает же.

А, да, про типы я к тому, что типизация должна быть строгая, согласно определенной схеме. С разрешением «пихать что угодно» только где надо (или если схема не написана, тогда «все лезет вовсюда» — тоже вариант).

Чтобы нельзя было просто взять и впихнуть в параметр с типом «IP-адрес» строку «тут был Вася, он поломал конфиг». Ну и автоматическое документирование (в схеме тут же можно и писать некий docstring параметра, который выдавать миру через xattrs) и прочие плюшки тут же.

> Уныние и yet another config file format. Никто не заботится.

Формат вовсе не "yet another". А остальное я ниасилил, иба многа букафф.

Поддержку C/C++ like комментариев не планируешь?

Ты забыл такую мелочь как смысл. Конфиг - это вариантная часть софта конфигурируемая _человеком_. И все должно проистекать из этой концепции и для его удобства.

> Поддержку C/C++ like комментариев не планируешь?

Сделать очень легко, но разве это нужно?

Не понимаю смысла в переменных в конфиге, просветите.
Если возникает такая необходимость - может в консервато^Wпрограмме просто параметры подправить?
Значит у вас конфиг не нормализован (измените базис;)

Пример. Как я понимаю, вы не хотите писать одно и то-же 2 раза
и вместо
----8<----
host=www
full_name=www.linux.org.ru
----8<----
хотите иметь возможность написать:
----8<----
host=www
full_name=$(host).linux.org.ru
----8<----
Но разве не проще/чище/надёжнее ввести в неймспейс "domain"? И иметь:
----8<----
host=www
domain=linux.org.ru
----8<----
и это - задача проги (а не админа) - складывать их вместе?

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

Anode

> Searching projects gives 1462 results

это только специально индексированные, а ещё в каждом проекте - свой.

На самом деле написать простой конфиг - пол-дня (берите, не жалко, 1463-й: http://sourceforge.net/project/showfiles.php?group_id=124759&package_id=1...)
Были-бы проекты, к которым конфиги писать;)

И ей-богу, быстрее написать с нуля, для каждой проги (для её специфики, её домейна имён, принимаемых типов и пр.) - чем разбираться с чужими АПИ и "юседжами".

Это _прога_ - должна знать типы, делать валидацию, а конфиг - только много букаф (и два делимитера, ну коммент можно ещё - чтобы памяти немного освободить).

ИМХО конечно (Разумеется на вкус и цвет... кто-то и без хмл не может)

Возьмём один и тот-же какой-нить Томкатовский конфиг как текст и как хмл. С одними и теми-же значениями.
-----------------------------
log4j.rootLogger=warn, file
log4j.appender.file.maxFileSize=100KB
log4j.appender.file.maxBackupIndex=5
log4j.appender.file.File=test.log
log4j.appender.file.threshold=info
log4j.appender.file.layout=org.apache.log4j.PatternLayout
log4j.appender.file.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n
-----------------------------
<?xml version="1.0" encoding="UTF-8"?>
<log4j:configuration>
<appender name="file"
class="org.apache.log4j.RollingFileAppender">
<param name="maxFileSize" value="100KB" />
<param name="maxBackupIndex" value="5" />
<param name="File" value="test.log" />
<param name="threshold" value="info"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern"
value="%d{ABSOLUTE} %5p %c{1}:%L - %m%n" />
</layout>
</appender>
<root>
<priority value="debug"></priority>
<appender-ref ref="file" />
<appender-ref ref="mail"/>
</root>
</log4j:configuration>
-------------------------
Пусть создатели хмл убьют себя об стену.
Не только >2 раза больше size, >3 раза больше слов (то-есть не нужных сущностей, где может быть ошибка, но которые не небходимы (см. пример 1).

А теперь затрём один симбол. Если затёрта скобка в хмл - п^Щсливай воду. В первом-же файле - менее 1% букв - критические для работы.


И не заикаемся про регекспы, седы, грепы и прочие поиско-подстановки в чистых строках.
Извините за МНОГАБУКАФ - наболело.

> Читаем в его документации первый же параграф и отвечаем:

Ну и получается примерно тоже самое.

А ссылки в конфигах - очень сомнительная фича, много лет прекрасно обходились без нее. Не, конечно польза от этого есть, но далеко не для всех и не всегда.

Неужели имеет смысл затирать один символ в _ЛЮБОМ_ виде конфига? а если затереть символ в текстовом файле?

По идее подразумевается, что XML руками не правится, и вся лишняя информация для улучшения разбора его тем ПО, для которого этот конфиг предназначается.