Библиотека для разбора config'ов
Vitaly Repin
Существует ли какая нибудь сишная library для
разбор конфигов?
Т.е. имеется файл tratata.cfg вида:
;Comment
Parametr1 Yes
Parametr2 False
StrPararmetr string
А я, возжелав значение параметра, пишу что-то вроде:
Parametr1=GetParamValue(Parametr1, "tratata.cfg");
В принципе написать самому парсер конфига несложно, но imho
работа уже кем то сделана. (?)
Good-bye!
WBW & WBR, Vitaly.
Boris Tobotras
Vitaly> Привет тебе, -[ALL_]-. Существует ли какая нибудь сишная library
Vitaly> для разбор конфигов? Т.е. имеется файл tratata.cfg вида:
Vitaly> ;Comment
Vitaly> Parametr1 Yes Parametr2 False StrPararmetr string
Vitaly> А я, возжелав значение параметра, пишу что-то вроде:
Vitaly> Parametr1=GetParamValue(Parametr1, "tratata.cfg");
Vitaly> В принципе написать самому парсер конфига несложно, но imho работа
Vitaly> уже кем то сделана. (?)
Угу. Представь себе, что tratata.cfg выглядит так:
#Comment
set Parametr1 Yes
set Parametr2 False
set StrParametr "string"
Представил? Тогда библиотека называется -ltcl. ;)
--
Best regards, -- Boris.
Машина должна работать, человек -- думать.
Valentin Nechayev
At 30-Jan-99 02:00, Vitaly Repin wrote:
> Существует ли какая нибудь сишная library для
> разбор конфигов?
> Т.е. имеется файл tratata.cfg вида:
>
> ;Comment
> Parametr1 Yes
> Parametr2 False
> StrPararmetr string
>
> А я, возжелав значение параметра, пишу что-то вроде:
>
> Parametr1=GetParamValue(Parametr1, "tratata.cfg");
>
> В принципе написать самому парсер конфига несложно, но imho
> работа уже кем то сделана. (?)
Ее каждый pаз делают заново. Догадываешься, почему?
--
NN
Sergey I. Clushin
А если надо еще SetParamValue(Parametr1, "tratata.cfg"),
то только самому дописывать, или что-то тоже есть? А то я
уже написал, но теперь подумал, что может зря...
--
Best regards.
Sergey.
Всего хорошего.
Сергей.
Boris Tobotras
>> Угу. Представь себе, что tratata.cfg выглядит так:
>>
>> #Comment
>> set Parametr1 Yes set Parametr2 False set StrParametr "string"
>>
>> Представил? Тогда библиотека называется -ltcl. ;)
Sergey> А если надо еще SetParamValue(Parametr1, "tratata.cfg"), то только
Sergey> самому дописывать, или что-то тоже есть? А то я уже написал, но
Sergey> теперь подумал, что может зря...
Hе надо ничего дописывать.
--
Best regards, -- Boris.
Погубят тебя слишком широкие возможности.
Vitaly Repin
[Понедельник Февpаль 01 1999 at 12:44], Valentin Nechayev [>>] Vitaly Repin:
>> ;Comment
>> Parametr1 Yes
>> Parametr2 False
>> StrPararmetr string
>>
>> А я, возжелав значение параметра, пишу что-то вроде:
>>
>> Parametr1=GetParamValue(Parametr1, "tratata.cfg");
>>
>> В принципе написать самому парсер конфига несложно, но imho
>> работа уже кем то сделана. (?)
VN> Ее каждый pаз делают заново. Догадываешься, почему?
Hет, расскажи.
Good-bye!
e-mail: vita...@lycosmail.com
WBW & WBR, Vitaly.
Valentin Nechayev
At 2-Feb-99 14:27, Vitaly Repin wrote:
> >> ;Comment
> >> Parametr1 Yes
> >> Parametr2 False
> >> StrPararmetr string
> >>
> >> А я, возжелав значение параметра, пишу что-то вроде:
> >>
> >> Parametr1=GetParamValue(Parametr1, "tratata.cfg");
> >>
> >> В принципе написать самому парсер конфига несложно, но imho
> >> работа уже кем то сделана. (?)
VN> Ее каждый pаз делают заново. Догадываешься, почему?
> Hет, расскажи.
Потому что общая часть, котоpую стоило бы вынести в библиотеку, настолько
мала, что сводится к strtok. Все остальное чеpесчуp специфично. Сpавни
конфиги golded'a, sendmail'a, gated'a и, для особо тяжелого пpимеpа,
/etc/termcap (обpатив особое внимание на 'tc=').
--
NN
Alec V. Ananchenko
>> >> В принципе написать самому парсер конфига несложно, но imho
>> >> работа уже кем то сделана. (?)
>VN> Ее каждый pаз делают заново. Догадываешься, почему?
>> Hет, расскажи.
>
>Потому что общая часть, котоpую стоило бы вынести в библиотеку, настолько
>мала, что сводится к strtok. Все остальное чеpесчуp специфично. Сpавни
>конфиги golded'a, sendmail'a, gated'a и, для особо тяжелого пpимеpа,
>/etc/termcap (обpатив особое внимание на 'tc=').
>
Странно, а вот в майкрософте с этим как-то смогли разобраться...
И очень удобно (по крайней мере в дельфях).
--
Alec V. Ananchenko
Sergey I. Clushin
>
> On 3 Feb 1999 03:35:05 +0300, Valentin Nechayev <n...@nn.kiev.ua> wrote:
> >> >> В принципе написать самому парсер конфига несложно, но imho
> >> >> работа уже кем то сделана. (?)
> >VN> Ее каждый pаз делают заново. Догадываешься, почему?
> >> Hет, расскажи.
> >
>
> Странно, а вот в майкрософте с этим как-то смогли разобраться...
> И очень удобно (по крайней мере в дельфях).
Угу. Для одной локальной машины, где нет дисков ro (не считая CD).
Только что делать в сети из 100 машин, где 99% конфигов
одинаковы и могут быть отданы по nfs, и только 1% специфичен для
конкретной машины. Из этого 1% в 99% случаев конфиоги могут
создаваться автоматом (ну адрес там проставить или права) и
рассылаться по сети rdis'ом или чем еще. Как это с идеологией
ms registry уживается?
Eugene Karpachov
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit
User-Agent: slrn/0.9.5.4 (UNIX)
Sat, 30 Jan 99 02:00:45 +0300 Vitaly Repin написал:
>А я, возжелав значение параметра, пишу что-то вроде:
>
>Parametr1=GetParamValue(Parametr1, "tratata.cfg");
>
>В принципе написать самому парсер конфига несложно, но imho
>работа уже кем то сделана. (?)
>
Еретический вопрос: а почему бы не getenv/putenv?
--
jk
Valentin Nechayev
At 3-Feb-99 17:38, Alec V. Ananchenko wrote:
VN> Ее каждый pаз делают заново. Догадываешься, почему?
> >> Hет, расскажи.
> >
> >Потому что общая часть, котоpую стоило бы вынести в библиотеку, настолько
> >мала, что сводится к strtok. Все остальное чеpесчуp специфично. Сpавни
> >конфиги golded'a, sendmail'a, gated'a и, для особо тяжелого пpимеpа,
> >/etc/termcap (обpатив особое внимание на 'tc=').
> Странно, а вот в майкрософте с этим как-то смогли разобраться...
> И очень удобно (по крайней мере в дельфях).
Пpостите, это с чем же таким pазобpались в майкpософте? С общим случаем
конфига???
--
NN
Alec V. Ananchenko
>VN> Ее каждый pаз делают заново. Догадываешься, почему?
>> >> Hет, расскажи.
>> >
>> >Потому что общая часть, котоpую стоило бы вынести в библиотеку, настолько
>> >мала, что сводится к strtok. Все остальное чеpесчуp специфично. Сpавни
>> >конфиги golded'a, sendmail'a, gated'a и, для особо тяжелого пpимеpа,
>> >/etc/termcap (обpатив особое внимание на 'tc=').
>> Странно, а вот в майкрософте с этим как-то смогли разобраться...
>> И очень удобно (по крайней мере в дельфях).
>
>Пpостите, это с чем же таким pазобpались в майкpософте? С общим случаем
>конфига???
>
Я не помню как зовуться эти функции, но они позволяют читать-писать в .ini файл
И построчно, и секциями, и integer и string. В общем программерам это должно быть ближе знакомо чем мне. И мне не понятно, чем это таким линукс-юникс отличается по конфигам от ини-файлов виндов, что к ним нельзя приделать приличный интерфейс. даже рулезы
sendmail.cf вполне можно расписать ИМХО. И структурированность получается и читаемость. Что еще для счастья не хватает?
--
Alec V. Ananchenko
Michael Marackaew
Alec V. Ananchenko <cop...@rtsnet.ru> wrote:
[...]
>>Потому что общая часть, котоpую стоило бы вынести в библиотеку, настолько
>>мала, что сводится к strtok. Все остальное чеpесчуp специфично. Сpавни
>>конфиги golded'a, sendmail'a, gated'a и, для особо тяжелого пpимеpа,
>>/etc/termcap (обpатив особое внимание на 'tc=').
>>
AVA> Странно, а вот в майкрософте с этим как-то смогли разобраться...
С чем? С 'tc=' ? А ты не смог? Ой-ой-ой!
AVA> И очень удобно (по крайней мере в дельфях).
А неудобно только в тапки... эээ...
--
Michael Marackaew
registered linux user #72631
m...@tm.penza.ru
Victor Wagner
>> >> В принципе написать самому парсер конфига несложно, но imho
>> >> работа уже кем то сделана. (?)
>> Hет, расскажи.
VN> Потому что общая часть, котоpую стоило бы вынести в библиотеку, настолько
VN> мала, что сводится к strtok. Все остальное чеpесчуp специфично. Сpавни
VN> конфиги golded'a, sendmail'a, gated'a и, для особо тяжелого пpимеpа,
VN> /etc/termcap (обpатив особое внимание на 'tc=').
Позволю себе не согласиться. Разбор опций командной строки еще более
тривиален, но тем не менее getopt в стандартной библиотеки есть. И это
очень правильно, поскольку все ленивые программисты его пользуют и в
результате у 90% программ синтаксис командной строки похожий.
Удосужься кто-нибудь в свое время в Беркли или ATT сделать аналогичный
getconf, у 90% программ (кроме, конечно, таких как sendmail) и конфиги
были был одинаковые. А так кто во что горазд. Кстати, идея такой
библиотеки всерьез обсуждалась в comp.os.linux.development.apps месяца
два назад.
VN> --
VN> NN
--
--------------------------------------------------------
I have tin news and pine mail...
Victor Wagner @ home = vi...@wagner.rinet.ru
Dmitry Hodos
>> В принципе написать самому парсер конфига несложно, но imho
>> работа уже кем то сделана. (?)
VN> Ее каждый pаз делают заново. Догадываешься, почему?
>> Hет, расскажи.
VN> Потому что общая часть, котоpую стоило бы вынести в библиотеку,
VN> настолько мала, что сводится к strtok.
А почему никто не упомянул lex/yacc?
--
Best regards, Dmitry Hodos
Oleg A. Volkov
>> И очень удобно (по кpайней меpе в дельфях).
>Угу. Для одной локальной машины, где нет дисков ro (не считая CD).
>pассылаться по сети rdis'ом или чем еще. Как это с идеологией
>ms registry уживается?
Он пpо .inf файлы говоpил, скоpее всего. А это тоже текстовые файлы, тоже
могут pассылать чем угодно. Да и Registry можно экспоpтиpовать в текстовый
вид, а потом импоpтиpовать на дpугую машину. А отсутствие единой системы
конфигуpационных файлов - это большой минус, IMHO.
С уважением, Олег.
Alexei Dets
"Alec V. Ananchenko" wrote:
>
> Я не помню как зовуться эти функции, но они позволяют читать-писать в .ini
файл
> И построчно, и секциями, и integer и string. В общем программерам это должно
> быть ближе знакомо чем мне. И мне не понятно, чем это таким линукс-юникс
> отличается по конфигам от ини-файлов виндов, что к ним нельзя приделать
> приличный интерфейс. даже рулезы
> sendmail.cf вполне можно расписать ИМХО. И структурированность получается и
> читаемость. Что еще для счастья не хватает?
В KDE давно уже это сделали. С конфигами работать одно удовольствие.
Алексей
Alexei Dets
Victor Wagner wrote:
>
> Удосужься кто-нибудь в свое время в Беркли или ATT сделать аналогичный
> getconf, у 90% программ (кроме, конечно, таких как sendmail) и конфиги
> были был одинаковые. А так кто во что горазд. Кстати, идея такой
> библиотеки всерьез обсуждалась в comp.os.linux.development.apps месяца
> два назад.
-lkdecore ;-)
Алексей
Max Valianskiy
Vitaly Repin <Vitaly...@p9.f267.n5030.z2.fidonet.org> writes:
VR> Существует ли какая нибудь сишная library для
VR> разбор конфигов?
VR> Т.е. имеется файл tratata.cfg вида:
VR>
VR> ;Comment
VR> Parametr1 Yes
VR> Parametr2 False
VR> StrPararmetr string
VR>
VR> В принципе написать самому парсер конфига несложно, но imho
VR> работа уже кем то сделана. (?)
в libgnome есть.
--
maxcom
Vitaly Repin
[Пятница Февpаль 05 1999 at 00:50], Victor Wagner [>>] Valentin Nechayev:
VW> Удосужься кто-нибудь в свое время в Беркли или ATT сделать
VW> аналогичный
VW> getconf, у 90% программ (кроме, конечно, таких как sendmail) и конфиги
VW> были был одинаковые. А так кто во что горазд. Кстати, идея такой
VW> библиотеки всерьез обсуждалась в comp.os.linux.development.apps месяца
VW> два назад.
И к чему пришли в результате обсуждения?
Valentin Nechayev
At 5-Feb-99 17:30, Dmitry Hodos wrote:
>>> В принципе написать самому парсер конфига несложно, но imho
>>> работа уже кем то сделана. (?)
VN> Ее каждый pаз делают заново. Догадываешься, почему?
> А почему никто не упомянул lex/yacc?
А ведь веpное замечание.
--
NN
Shura Shuracov
[ skip ]
> Позволю себе не согласиться. Разбор опций командной строки еще более
> тривиален, но тем не менее getopt в стандартной библиотеки есть. И это
> очень правильно, поскольку все ленивые программисты его пользуют и в
> результате у 90% программ синтаксис командной строки похожий.
Позволю себе не согласиться. Синтаксис командной строки описан в одном
из стандартов группы POSIX. IMHO, стандартная библиотека возможна благодаря
стандарту на синтаксис (возможно, de-facto), а не наоборот.
--
Shura Shuracov 2:5020/18.25 AKA 1136.4 AKA 794.106
AKA shur...@chat.ru
Artem Bondarenko
At 05 Feb 99 00:50:53, Victor Wagner wrote to Valentin Nechayev:
VW> Удосужься кто-нибудь в свое время в Беркли или ATT сделать аналогичный
VW> getconf, у 90% программ (кроме, конечно, таких как sendmail) и конфиги
VW> были был одинаковые. А так кто во что горазд. Кстати, идея такой
VW> библиотеки всерьез обсуждалась в comp.os.linux.development.apps месяца
VW> два назад.
И что решили? Быть или не быть?
[*SPEED_N'POWER_metal* Team]
Oleg Polyanski
>>> >VN> Ее каждый pаз делают заново. Догадываешься, почему?
>>> Стpанно, а вот в майкpософте с этим как-то смогли pазобpаться... И очень
>>> удобно (по кpайней меpе в дельфях).
>> Угу. Для одной локальной машины, где нет дисков ro (не считая CD).
olegv> ...
>> pассылаться по сети rdis'ом или чем еще. Как это с идеологией ms registry
>> уживается?
olegv> Он пpо .inf файлы говоpил, скоpее всего. А это тоже текстовые файлы,
olegv> тоже могут pассылать чем угодно. Да и Registry можно экспоpтиpовать в
olegv> текстовый вид, а потом импоpтиpовать на дpугую машину. А отсутствие
olegv> единой системы конфигуpационных файлов - это большой минус, IMHO.
в юниксах данные registry хранятся в каталоге /etc.
Alexander L. Belikoff
> Hello Dmitry Hodos!
>
> At 5-Feb-99 17:30, Dmitry Hodos wrote:
>
> >>> В принципе написать самому парсер конфига несложно, но imho
> >>> работа уже кем то сделана. (?)
> VN> Ее каждый pаз делают заново. Догадываешься, почему?
> > А почему никто не упомянул lex/yacc?
>
> А ведь веpное замечание.
Потому, что синтаксис конфигов настолько тривиален, что генерить для
них яковский конечный автомат - это как атомной бомбой по мирной
демонстрации. Кроме того, по крайней мере до последнего времени, Лекс
с Якком были... ммм... ну, скажем так, не совсем реентрабельны.
Поэтому, человека, обращающегося к данной библиотеке, и использующего
сладкую парочку в своей программе, ждали бы ба-а-а-альшие
неприятности...
--
Alexander L. Belikoff
Bloomberg L.P. / BFM Financial Research Ltd.
ab...@vallinor4.com, ab...@bfr.co.il
Alexander L. Belikoff
> Valentin Nechayev <Valentin...@f400.n5020.z2.fidonet.org> wrote:
> >> >> В принципе написать самому парсер конфига несложно, но imho
> >> >> работа уже кем то сделана. (?)
> VN>> Ее каждый pаз делают заново. Догадываешься, почему?
> >> Hет, расскажи.
>
> VN> Потому что общая часть, котоpую стоило бы вынести в библиотеку, настолько
> VN> мала, что сводится к strtok. Все остальное чеpесчуp специфично. Сpавни
> VN> конфиги golded'a, sendmail'a, gated'a и, для особо тяжелого пpимеpа,
> VN> /etc/termcap (обpатив особое внимание на 'tc=').
>
> Позволю себе не согласиться. Разбор опций командной строки еще более
> тривиален, но тем не менее getopt в стандартной библиотеки есть. И это
> очень правильно, поскольку все ленивые программисты его пользуют и в
> результате у 90% программ синтаксис командной строки похожий.
>
> Удосужься кто-нибудь в свое время в Беркли или ATT сделать аналогичный
> getconf, у 90% программ (кроме, конечно, таких как sendmail) и конфиги
> были был одинаковые. А так кто во что горазд. Кстати, идея такой
> библиотеки всерьез обсуждалась в comp.os.linux.development.apps месяца
> два назад.
У меня ... самого ... две таких ... библиотеки (всё, больше не могу
удержаться - мат-перемат).
Может, скооперируемся и соорудим чего-то достойное для контрибуции в
GNU? Мне эта идея уже давно покоя на даёт...
Alexei Dets
Zahar Kiselev wrote:
>
> At 01 Feb 99 12:44:42, Valentin Nechayev wrote to Vitaly Repin:
>
> >> В принципе написать самому парсер конфига несложно, но imho
> >> работа уже кем то сделана. (?)
> VN> Ее каждый pаз делают заново. Догадываешься, почему?
> Отсутствие такой библиотеки приводит к появлению таких разборщиков как
Есть такие библиотеки, есть. Как минимум в двух проектах которые хоть
как-то подумали об интеграции - kde и gnome. В KDE это kdecore, в gnome
- не знаю.
Алексей
Zahar Kiselev
At 01 Feb 99 12:44:42, Valentin Nechayev wrote to Vitaly Repin:
>> В принципе написать самому парсер конфига несложно, но imho
>> работа уже кем то сделана. (?)
VN> Ее каждый pаз делают заново. Догадываешься, почему?
Я не догадываюсь и тоже ищу библиотеку для разбора конфигов.
Отсутствие такой библиотеки приводит к появлению таких разборщиков как
у qecho - вообще ничего не проверяющих и падающих в core от малейшей неточности
в конфиге вместо того, чтобы хотябы указать на не понравившуюся строку.
Zahar
Viktor Krapivin
Как-то Friday February 05 1999 17:30, Dmitry Hodos писал Valentin Nechayev:
>>> В пpинципе написать самому паpсеp конфига несложно, но imho
>>> pабота уже кем то сделана. (?)
VN>> Ее каждый pаз делают заново. Догадываешься, почему?
>>> Hет, pасскажи.
VN>> Потому что общая часть, котоpую стоило бы вынести в библиотеку,
VN>> настолько мала, что сводится к strtok.
DH> А почему никто не упомянул lex/yacc?
Потому что в некотоpых случаях задать *.l может быть гоpаздо тpуднее, чем
кажется на пеpвый взгляд. Или pуками - а тогда кpоме обpаботки комментаpиев что
получится? Тот же strtok!
В пpостейшем случае это сводится к пpимеpно следующему коду -
-------------- это sample.l
%{
#include "y.tab.h"
%}
%%
# [^\n\r]+ ;
[ \t]+ ;
\n return EOL;
[A-Za-z_][A-Za-z0-9_\.]+ return IDENT;
[0-9]+ return NUMBER;
\= return EQUAL;
\"[^\"]+\" return STRING;
\'[^\']+\' return STRING;
--------------
-------------- это sample.y - только гpамматика (не исключено с ошибками)
%token NUMBER IDENT EOL EQUAL STRING
%%
file: line
|
file line
;
line: IDENT equal options EOL
|
EOL /* empty lines here */
;
options: option
|
options option
;
option: IDENT
|
NUMBER
|
STRING
;
equal: EQUAL
|
;
--------------
И о чем тут говоpить? Вот если делать что-нибудь посложнее - напpимеp
XF86Config, тогда да - есть pезон использовать lex/yacc. Hо это не имеет смысла
для 90% конфигов.
Пpиведенный пpимеp (набит не отходя от кассы) pазбиpает конфиг следующего вида
(символ '=' можно опускать, но так имхо нагляднее). Пpиведена голая гpамматика
без соответствующего кода - вставьте сами 8)
------------------
#######################
# This is config sample
#
numeric_value_1 10 # Sample - simple numeric value
numeric_value_2 = 20 # --//--
numeric_value_list = 10 20 30 40 # Numeric value list
string_value_list = 'string 1' "string 2" # String list
# reference list - you need to make your structures properly 8)
ident_ref_list = numeric_value_1 string_value_list
boolean_value = off # Sample - boolean value
------------------
Viktor
Victor Wagner
AD> From: Alexei Dets <de...@services.ru>
AD> Hi!
AD> Victor Wagner wrote:
>>
>> Удосужься кто-нибудь в свое время в Беркли или ATT сделать аналогичный
>> getconf, у 90% программ (кроме, конечно, таких как sendmail) и конфиги
>> были был одинаковые. А так кто во что горазд. Кстати, идея такой
>> библиотеки всерьез обсуждалась в comp.os.linux.development.apps месяца
>> два назад.
AD> -lkdecore ;-)
Имелась в виду библиотека для нормальных юниксных программ а не C++ -
ных GUI. Что-то на уровне стандартного GETOPT. kde, например, у меня не
стоит и стоять никогда не будет, ибо попытку посадить винды поверх ядра
Unix я считаю тупиковым путем развития. В принципе, меня даже gnome
не устраивает как Desktop for Unix, несмотря на независимость от
конкретного языка программирования и наличие встроенного скриптового
языка. Правильным десктопом для Unix я сочту тот, где есть аналог
shell, который позволяет столь же удобно объединять отдельные операции в
скрипты (желательно мышкой, раз уж это desktop).
А вот библиотека для конфигов нужна и командно-строчным программам и
программам с curses-интерфейсом.
AD> Алексей
Victor Wagner
DH> From: Dmitry Hodos <h...@hodos.omsk.uucp>
>>>>>> "VN" == Valentin Nechayev writes:
VN>> Потому что общая часть, котоpую стоило бы вынести в библиотеку,
VN>> настолько мала, что сводится к strtok.
DH> А почему никто не упомянул lex/yacc?
Потому что во-первых, криво, во-вторых overkill. Если мне понадобится
полнофункциональный macro-язык, я уж лучше tcl-интерпретатор туда
вкручу или guile.
DH> --
DH> Best regards, Dmitry Hodos
Ilya Popov
Mon, 08 Feb 99 04:06:09 +0300 Alexander L. Belikoff wrote:
>> > А почему никто не упомянул lex/yacc?
>>
>> А ведь веpное замечание.
ALB> Потому, что синтаксис конфигов настолько тривиален, что генерить для
ALB> них яковский конечный автомат - это как атомной бомбой по мирной
ALB> демонстрации. Кроме того, по крайней мере до последнего времени, Лекс
ALB> с Якком были... ммм... ну, скажем так, не совсем реентрабельны.
Hа сколько я помню, эта нереентерабельность лечилась относительно просто -
убиранием глобальных переменных в сгенеренном анализаторе.
ALB> Поэтому, человека, обращающегося к данной библиотеке, и использующего
ALB> сладкую парочку в своей программе, ждали бы ба-а-а-альшие
ALB> неприятности...
--
Best regards, Ilya.
Dmitry Hodos
DH> А почему никто не упомянул lex/yacc?
VK> В пpостейшем случае это сводится к пpимеpно следующему коду -
VK> -------------- это sample.l
[skip]
VK> -------------- это sample.y - только гpамматика (не исключено с ошибками)
[skip]
VK> И о чем тут говоpить? Вот если делать что-нибудь посложнее - напpимеp
VK> XF86Config, тогда да - есть pезон использовать lex/yacc. Hо это не
VK> имеет смысла для 90% конфигов.
Что значит не имеет смысла? Ты сам только что прекрасно показал, что для
простых конфигов *.l и *.y пишутся элементарно (а если осталась заготовка
от предыдущего проекта -- то и вовсе без подключения высшей нервной
деятельности ;)). Почему уже второй человек высказывается в том духе, что
lex/yacc -- это монстры, и если уж чего на них парсить, так уж никак не
меньше, чем какой-нить SQL? Где эти таинственные расходы, из-за которых
применение lex/yacc не может быть оправдано? Почему лучше пользоваться
какими-то эзотерическими либами, появившимися вчера?
lex/yacc -- It's portable, в конце концов.
Andrew B. Sapozhnikov
> >>>>> "VK" == Viktor Krapivin writes:
> DH> А почему никто не упомянул lex/yacc?
> VK> XF86Config, тогда да - есть pезон использовать lex/yacc. Hо это не
> VK> имеет смысла для 90% конфигов.
> Что значит не имеет смысла? Ты сам только что прекрасно показал, что для
> простых конфигов *.l и *.y пишутся элементарно (а если осталась заготовка
> от предыдущего проекта -- то и вовсе без подключения высшей нервной
> деятельности ;)). Почему уже второй человек высказывается в том духе, что
> lex/yacc -- это монстры, и если уж чего на них парсить, так уж никак не
> меньше, чем какой-нить SQL? Где эти таинственные расходы, из-за которых
> применение lex/yacc не может быть оправдано? Почему лучше пользоваться
> какими-то эзотерическими либами, появившимися вчера?
> lex/yacc -- It's portable, в конце концов.
Да чего спорить, если есть готовые разборщики любых конфигов и не только
с гововым синтаксисом, но и с готовой семантикой? Это интерпретаторы.
Создаем в своей C-задаче Tcl интерпретатор (можно SafeTcl, если конфиг
вражеский) натравливаем его на конфиг. По окончании жизнедеятельности
смотрим необходимые нам глобальные переменные... подходит для создания
самых навороченных, гибких и "умных" конфигов.
------------------------- myprog.c ----------------------------
#include <stdio.h>
#include <tcl.h>
int main() {
Tcl_Interp *config;
char *ptr;
config=Tcl_CreateInterp();
if(Tcl_EvalFile(config,"~/.myconfig")==TCL_ERROR) {
fprintf(stderr,"Error: %s\n",config->result);
exit(1);
}
ptr=Tcl_GetVar(config,"source_addr",TCL_GLOBAL_ONLY);
printf("Source Address: %s\n",ptr);
ptr=Tcl_GetVar(config,"target_addr",TCL_GLOBAL_ONLY);
printf("Target Address: %s\n",ptr);
ptr=Tcl_GetVar(config,"ttl",TCL_GLOBAL_ONLY);
printf("TTL: %s\n",ptr);
Tcl_DeleteInterp(config);
}
-------------------------- EOF ------------------------------------
------------------------ ~/.myconfig ----------------------------
# Comment
puts "Hello from config file"
set global_config "/usr/share/myprog/config"
if [file readable $global_config] {
source $global_config
}
set source_addr "192.168.0.1"
set target_addr "172.16.10.10"
set ttl [expr 64+16]
---------------------------- EOF ---------------------------------
Best regards, Andrew Sapozhnikov.
Ilya Popov
Thu, 11 Feb 99 18:10:22 +0300 Andrew B. Sapozhnikov wrote:
ABS> Да чего спорить, если есть готовые разборщики любых конфигов и не только
ABS> с гововым синтаксисом, но и с готовой семантикой? Это интерпретаторы.
ABS> Создаем в своей C-задаче Tcl интерпретатор (можно SafeTcl, если конфиг
ABS> вражеский) натравливаем его на конфиг. По окончании жизнедеятельности
ABS> смотрим необходимые нам глобальные переменные... подходит для создания
ABS> самых навороченных, гибких и "умных" конфигов.
Минусов тоже полно, это очевидно. Сам Tcl - не такая уж мелочь чтобы его всюду
за собой таскать. Одно дело на нем программы писать, а другое - вызывать из
своей программы только для чтения конфигов.
--
Best regards, Ilya.
Viktor Krapivin
Как-то Thursday February 11 1999 18:10, Andrew B Sapozhnikov писал All:
>> DH> А почему никто не упомянул lex/yacc?
>> VK> И о чем тут говоpить? Вот если делать что-нибудь посложнее -
>> VK> напpимеp XF86Config, тогда да - есть pезон использовать
>> VK> lex/yacc. Hо это не имеет смысла для 90% конфигов.
>> Что значит не имеет смысла? Ты сам только что пpекpасно показал, что
>> для пpостых конфигов *.l и *.y пишутся элементаpно
вот пpимеpно то чего достаточно для pазбоpа конфига вида
--------------------------
# Parameters for hypotetic
# program
# Adjust brightness
# valid range 1 .. 100
adjustBrightness = yes
brightnessValue = 50
--------------------------
--------------------------
while(!feof(stream)){
if(fscanf(stream, "%s = %s\n",key, value)<2 || *key=='#') continue;
if(sscanf(value, "%d", &number)) // numeric value
else // text value
}
--------------------------
Гоpаздо пpоще, не так ли? Возможностей конечно поменьше, да и обpаботкой ошибок
не пахнет, зато пpоще некуда (и насколько меньше - смотpи мой пpимеp
на lex/yacc).
>> Почему уже втоpой человек высказывается в том духе, что lex/yacc --
>> это монстpы, и если уж чего на них паpсить, так уж никак не меньше,
>> чем какой-нить SQL?
Ты же не забиваешь гвозди микpоскопом?
>> Где эти таинственные pасходы, из-за котоpых пpименение lex/yacc не
>> может быть опpавдано?
Почему же - очень даже может быть опpавдано - для XF86Config (сложность - уже
есть смысл), sendmail.cf (pазмеpы), termcap (вот где монстp 8) - и то и
дpугое),
конфиги апача и некотоpые дpугие. Hо использовать lex/yacc для пpимеpа свеpху -
не тот уpовень.
>> Почему лучше пользоваться какими-то эзотеpическими либами,
>> появившимися вчеpа?
"Используй то, что под pукою, и не ищи себе дpугое" (С) мультфильм.
Эти библиотеки как pаз оpиентиpованы на малую сложность маленьких текстовых [в
том числе конфигуpационных] файлов.
>> lex/yacc -- It's portable, в конце концов.
Пpимеp свеpху - не менее поpтабильный.
AS> Да чего споpить, если есть готовые pазбоpщики любых конфигов и не
AS> только с гововым синтаксисом, но и с готовой семантикой?
AS> Это интеpпpетатоpы. Создаем в своей C-задаче Tcl интеpпpетатоp (можно
AS> SafeTcl, если конфиг вpажеский) натpавливаем его на конфиг.
А потом пpи установке долго упpашиваем поставить Tcl. Или Python. Или perl -
кто во что гоpазд. Хотя для 90% задач конфиг немногим отличается от
пpиведенного
свеpху. Или тащим этот (стоpонний! Часто GNUтый!) с собой - что имхо еще хуже -
для коммеpческого пpоекта.
AS> По окончании жизнедеятельности смотpим необходимые нам глобальные
AS> пеpеменные... подходит для создания самых навоpоченных, гибких и
AS> "умных" конфигов.
Viktor
c...@materials.kiev.ua
>> И построчно, и секциями, и integer и string. В общем программерам
>> это должно быть ближе знакомо чем мне. И мне не понятно, чем это
>> таким линукс-юникс отличается по конфигам от ини-файлов виндов, что
>> к ним нельзя приделать приличный интерфейс. даже рулезы sendmail.cf
>> вполне можно расписать ИМХО. И структурированность получается и
>> читаемость. Что еще для счастья не хватает?
AD> В KDE давно уже это сделали. С конфигами работать одно
AD> удовольствие.
Фиг. С комментариями у них проблемы. Лучше бы они воспользовались Xовыми
ресурсами, благо Xrm при чтении .Xdefaults пользует cpp, со всеми
вытекающими.
AD> Алексей
--
Soiree,
Cyril.
: Будучи откpыто опубликованным в ночь с 31 Октябpя на 1 Декабpя...
c...@materials.kiev.ua
>> Удосужься кто-нибудь в свое время в Беркли или ATT сделать
>> аналогичный getconf, у 90% программ (кроме, конечно, таких как
>> sendmail) и конфиги были был одинаковые. А так кто во что
>> горазд. Кстати, идея такой библиотеки всерьез обсуждалась в
>> comp.os.linux.development.apps месяца два назад.
AD> -lkdecore ;-)
Hе катит уже по той причине, что либа там плюсовая.
Victor Wagner
DH> деятельности ;)). Почему уже второй человек высказывается в том духе, что
DH> lex/yacc -- это монстры, и если уж чего на них парсить, так уж никак не
DH> меньше, чем какой-нить SQL? Где эти таинственные расходы, из-за которых
Потому что. Ты когда-нибудь смотрел в код, сгенерированный yacc?
Я смотрел. После того как меня в bugtraq перед всем миром срамили за
использование strcpy при разборе конфига (при этом buffer overflow могло
теоретически возникнуть либо по инициативе запускающего юзера, либо по
инициативе рута) я, пожалуй использовать код, для которого наличие
неициализированных переменных нормально, не буду.
К тому же, yacc в linux это как правило bison, соответственно,
получаемый код это GPL. GPL, а не LGPL.
А как это портировать, скажем в msdos?
И вообще, зачем программе в 300 строк парсер конфига на 500?
К тому же, есть у меня приятель который специалист по проектированию
компиляторов. Так он при каждом моем упоминании yacc начинает брызгать
слюной и материться. И действительно, парсер для одного и того же
синтаксиса написанный по его рекомендациям на взаимно рекурсивных
процедурах, получается раз в 10 компактнее чем на yacc. Т.е. код на C
соизмерим по размерам с файлом .y.
Причем речь идет не о вырожденных случаях типа конфигов, а о
полномасштабыных арифметических выражениях.
В общем, yacc это такой c-shell. С виду кажется удобным, а понимающими
людьми "considered harmful".
Victor Wagner
SS> Victor Wagner wrote at Fri, 05 Feb 99 00:50:53 +0300:
SS> [ skip ]
>> Позволю себе не согласиться. Разбор опций командной строки еще более
>> тривиален, но тем не менее getopt в стандартной библиотеки есть. И это
>> очень правильно, поскольку все ленивые программисты его пользуют и в
>> результате у 90% программ синтаксис командной строки похожий.
SS> Позволю себе не согласиться. Синтаксис командной строки описан в одном
SS> из стандартов группы POSIX. IMHO, стандартная библиотека возможна благодаря
SS> стандарту на синтаксис (возможно, de-facto), а не наоборот.
А что такое стандарт de-facto? Это наличие реализации, которой все
пользуются. Соответственно создание и некоторая раскрутка такой
универсальной библиотеки и привела бы к появлению оного стандарта
de-facto.
Alexei Dets
Victor Wagner wrote:
>
> >> Удосужься кто-нибудь в свое время в Беркли или ATT сделать аналогичный
> >> getconf, у 90% программ (кроме, конечно, таких как sendmail) и конфиги
> >> были был одинаковые. А так кто во что горазд. Кстати, идея такой
> >> библиотеки всерьез обсуждалась в comp.os.linux.development.apps месяца
> >> два назад.
>
> AD> -lkdecore ;-)
>
> программам с curses-интерфейсом.
Я имел в виду, что работа с конфигами там довольно хорошо сделана. Можно
вероятно код за основу взять и сделать более независимый от Qt вариант.
Алексей
Alexei Dets
c...@materials.kiev.ua wrote:
>
> >> И построчно, и секциями, и integer и string. В общем программерам
> >> это должно быть ближе знакомо чем мне. И мне не понятно, чем это
> >> таким линукс-юникс отличается по конфигам от ини-файлов виндов, что
> >> к ним нельзя приделать приличный интерфейс. даже рулезы sendmail.cf
> >> вполне можно расписать ИМХО. И структурированность получается и
> >> читаемость. Что еще для счастья не хватает?
>
> AD> В KDE давно уже это сделали. С конфигами работать одно
> AD> удовольствие.
>
> Фиг. С комментариями у них проблемы. Лучше бы они воспользовались Xовыми
> ресурсами, благо Xrm при чтении .Xdefaults пользует cpp, со всеми
> вытекающими.
С комментариями да. Hо это мелочь по сравнению с остальным - можно
стараться давать понятные названия пунктам конфига. Да и исправить они
это планируют. А вот использовать .Xdefaults как _конфиг_ различных
программ - IMHO было бы верхом идиотизма.
Алексей
Alexander L. Belikoff
> Shura Shuracov <Shura_S...@p106.f794.n5020.z2.fidonet.org> wrote:
> SS> Victor Wagner wrote at Fri, 05 Feb 99 00:50:53 +0300:
> SS> [ skip ]
>
> >> Позволю себе не согласиться. Разбор опций командной строки еще более
> >> тривиален, но тем не менее getopt в стандартной библиотеки есть. И это
> >> очень правильно, поскольку все ленивые программисты его пользуют и в
> >> результате у 90% программ синтаксис командной строки похожий.
>
> SS> Позволю себе не согласиться. Синтаксис командной строки описан в одном
> SS> из стандартов группы POSIX. IMHO, стандартная библиотека возможна благодаря
> SS> стандарту на синтаксис (возможно, de-facto), а не наоборот.
>
> А что такое стандарт de-facto? Это наличие реализации, которой все
> пользуются. Соответственно создание и некоторая раскрутка такой
> универсальной библиотеки и привела бы к появлению оного стандарта
> de-facto.
Настырно повторюсь...
1. Библиотека должна быть частью GNU project и рекомендована FSF, как
"стандартное" (в смысле GNU) средство работы с конфигами.
2. Библиотека не должна быть очень уж однобокой. Тут все говорят о
вводе конфиг-данных, но никто и не заикался о выводе. Моя древняя
библиотека умела делать и то и другое. Расплата - надо было строить
дерево данных и держать его в памяти (не только из-за этого, правда
- дерево необходимо и для того, чтобы не перечитывать файл каждый
раз, когда требуется считать ещё один параметр)
3. Библиотека должна быть заточена под "современный" UNIX, а не
"Research Version 6" - библиотека должна быть реентрантна (для
нескольких конфиг-файлов), и корректна в многопоточных программах.
4. Библиотека должна быть написана на ANSI + K&R C. C++ - хороший
язык, но основной язык программ в UNIX - это C.
Я, в далёком детстве, писал библиотеку, удовлетворяющую пп. 2 и 4
(только ANSI C). В какой-то момент собирался переписать её,
руководствуясь всеми вышеприв. требованиями, но отвлёкся и забыл.
Предлагаю:
1. Поработать над вышеприведенным "ТЗ", дабы решить, какие
возможности мы хотим, а какие нет.
2. НАПИСАТЬ ЭТУ ДУРУ В КОНЦЕ КОНЦОВ!!! :-)
3. Отдать её FSF.
Комментарии?..
Alexander Vorobiev
Прежде чем вступать в дискуссию, я хочу сделать некое псевдолирическое
отступление. Оно очень короткое и заключается в том, что чрезмерное
упрощение проблемы может привести в последствии к чрезмерно
ограниченному, хотя и весьма эффективному, решению.
А теперь по существу дела. Рано или поздно, при разрабоке мало-мальски
сложной программы мы сталкиваемся с проблемой сохранения ее
"состояния" между запусками. В юниксоподобных системах это традиционно
делается путем создания текстового файла. Имея определенные
недостатки, этот метод обладает существенными достоинствами, которые
должны быть очевидны для участников данной дискуссии ;)
При этом желательно, чтобы программа предоставляла известную гибкость
в текстуальном описании таких состояний. В первую очередь в голову
приходит сохранить значения дюжины переменных и на этом успокоиться. К
большому сожалению, на этом успокаиваются авторы большинства
программ. Что я имею в виду, скажу позднее, а пока рассмотрим только
этот вариант.
Итак, мы решили сохранить значения переменных. Как мы это делаем?
Решение первое: взять и записать значения нужных нам переменных подряд
через запятую или пробел - 1, 13, "вверх", 3.14, 0xAD3. Программа
знает, где что? Знает. Автор знает? Тоже знает. Прекрасно! Пример -
~/.ee/settings Судя по названию, это - файл с настройками программы
electric eyes. еще пример ~/.clockrc Любопытные могут заглянуть туда и
потом рассказать мне, что именно эти настройки настраивают.
Однако, с увеличением количества желательных к запоминанию параметров
с одной стороны, и количества пользователей с другой стороны, такой
конфигурационный файл нас удовлетворять перестает и мы решаем
поместить туда и имена переменных по схеме:
имяпеременной, пробел|знак равенства|двоеточие|ктовочтогоразд, значение.
типа
Library_path = /usr/lib/my_super_irc_client
потом нам это тоже быстро надоедает и мы добавляем туда сначала
возможность комментариев
# This is library path
Library_path = /usr/lib/my_super_irc_client
а потом, а зависимости от остроты ума, желания выпендриться, и,
наконец, реальных требований программы :) в файле настройки начинают
появляться возможности описания:
- иерархий переменных/сущностей. пример - ресурсы X
- именованных логических групп переменных. пример - .mwmrc (там так
меню описываются, хотя, возможно, пример и не очень удачный)
- неких правил, по которым программа может менять поведение. пример
все придумают сами ;))))
и так далее до бесконечности
что же получается в пределе? в общем случае, кроме значений
переменных, к состоянию программы, заслуживающему сохранения,
можно отнести и простые _функции_ от этих переменных (для разных
значений слова "простые" ;)
Все уже поняли, куда я клоню. Любая попытка придумать "библиотеку для
разбора configов" рано или поздно приведет к проблеме создания некоего
языка, причем чем дальше, тем все более изощренного. И эта проблема
давным-давно решена (как и большинство проблем на свете). Extension
languages (языки расширения) общего назначения существуют сто лет в
обед. Tcl, guile - самые очевидные примеры. И нечего тут велосипед
изобретать. Я уже слышу толпу, кричащую, зачем, мол, программе на 10
кило, библиотека на 500? Ответ - дальше :)
ab...@bfr.co.il (Alexander L. Belikoff) writes:
> Настырно повторюсь...
примеры у меня будут из guile, поэтому заранее прошу прощения у
оппонента, зная его отношение к данному языку :)
>
> 1. Библиотека должна быть частью GNU project и рекомендована FSF, как
> "стандартное" (в смысле GNU) средство работы с конфигами.
c guile так оно и есть
>
> 2. Библиотека не должна быть очень уж однобокой. Тут все говорят о
> вводе конфиг-данных, но никто и не заикался о выводе. Моя древняя
> библиотека умела делать и то и другое. Расплата - надо было строить
> дерево данных и держать его в памяти (не только из-за этого, правда
> - дерево необходимо и для того, чтобы не перечитывать файл каждый
> раз, когда требуется считать ещё один параметр)
средства генерации кода в обоих языках есть очень
продвинутые. особенно в guile, но там это просто неотъемлемое свойство
лиспоподобного языка
> 3. Библиотека должна быть заточена под "современный" UNIX, а не
> "Research Version 6" - библиотека должна быть реентрантна (для
> нескольких конфиг-файлов), и корректна в многопоточных программах.
насчет этого зуб не дам, хотя оба языка достаточно современны и
активно поддерживаются/разрабатываются. а корректная поддержа
многопоточности сейчас, по-моему, основная красная тряпка перед
разработчиками всего на свете
> 4. Библиотека должна быть написана на ANSI + K&R C. C++ - хороший
> язык, но основной язык программ в UNIX - это C.
разумеется
> Предлагаю:
>
> 1. Поработать над вышеприведенным "ТЗ", дабы решить, какие
> возможности мы хотим, а какие нет.
аппетит, как известно, приходит во время сами знаете чего. чем дальше
будет идти обсуждение, тем больше будет возможностей, "которые мы
хотим". и разработчики extension languages через это проходили много
раз. результаты мы видим - получаются языки сравнимой сложности
>
> 2. НАПИСАТЬ ЭТУ ДУРУ В КОНЦЕ КОНЦОВ!!! :-)
>
> 3. Отдать её FSF.
>
> Комментарии?..
да я, собственно, уже все прокомментировал. основное возражение здесь
- это размер вспомогательных библиотек. но тут, вспоминая давний спор
в comp.lang.lisp, аргумент простой - на размер libc мы не жалуемся?
так все идет к тому, что libguile скоро станет неотъемлемой частью
любой системы, использующей gnu-программы. а значит, и нечего тут
огород городить. уже сейчас вероятность наличия ее в системе
достаточно велика, учитывая рост числа любителей gnome. и потом, "при
современном развитии печатного дела на западе" c одной стороны и "в
наше время, когда космические корабли бороздят большой театр" c другой
стороны, 500 кило - это несерьезно. полмира пишет на, извиняюсь,
visual basic поделки из десяти строк и никто не жалуется на
необходимость тащить за собой его рантайм. хотя тут можно поспорить ;)
Ну и последний (наконец-то!) аргумент несколько философского
содержания. Добавление языка расширения в программу часто заставляет
задуматься о "разделении ответственности" и вынесение части ее
функциональности в "config-файл" на глаза пользователю. какие это
открывает перспективы я говорить не буду - убедительный пример каждый
для себя придумает сам.
ну и совсем наконец, прошу прощения за такое длинное письмо и за то,
что сказал вещи, которые для многих будут самоочевидны.
Александр
--
People who like this sort of thing will find this is the sort of thing
they like.
Abraham Linkoln
Sergey Kirpa
Здравствуйте, уважаемый(ая) Alexander L Belikoff!
─═─ Понедельник 15 февраля 1999г. 03:03, Alexander L Belikoff писал(а) к All:
[ ... ]
AB> Предлагаю:
AB> 1. Поработать над вышеприведенным "ТЗ", дабы решить, какие
AB> возможности мы хотим, а какие нет.
AB> 2. HАПИСАТЬ ЭТУ ДУРУ В КОHЦЕ КОHЦОВ!!! :-)
AB> 3. Отдать её FSF.
AB> Комментарии?..
Уже написали gdbm.
Зачем ещё одну делать?
С наилучшими пожеланиями - Sergey.
Yuriy Kaminskiy
>>>>> On 12:00 13/2/1999, Victor Wagner <2:5020/219.27> writes:
VW> К тому же, yacc в linux это как правило bison, соответственно,
VW> получаемый код это GPL. GPL, а не LGPL.
Чушь. RFTM, да внимательнее. Полученный код - это _не_ GPL и даже не
LGPL.
VW> А как это портировать, скажем в msdos?
А что там надо портировать 8-0?
VW> И вообще, зачем программе в 300 строк парсер конфига на 500?
500 строк чего? Вывода bison+yacc? А ты думаешь, что _в коде_ это много
больше, чем примитивный разборщик?
VW> К тому же, есть у меня приятель который специалист по
VW> проектированию компиляторов. Так он при каждом моем упоминании
VW> yacc начинает брызгать слюной и материться. И действительно,
VW> парсер для одного и того же синтаксиса написанный по его
VW> рекомендациям на взаимно рекурсивных процедурах, получается раз в
VW> 10 компактнее чем на yacc. Т.е. код на C соизмерим по размерам с
VW> файлом .y.
А по скорости работы? А по размеру кода? yacc-то по табличкам бегает.
--
Yuriy Kaminskiy.
PS парсер для пацкаля на взаимно-рекурсивных процедурах - это и я смогу
:) А вот попробуй для, скажем, Си :)
Yuriy Kaminskiy
>> Фиг. С комментариями у них проблемы. Лучше бы они воспользовались
>> Xовыми ресурсами, благо Xrm при чтении .Xdefaults пользует cpp, со
>> всеми вытекающими.
AD> стараться давать понятные названия пунктам конфига. Да и исправить
AD> они это планируют. А вот использовать .Xdefaults как _конфиг_
AD> различных программ - IMHO было бы верхом идиотизма.
Почему в ~/.Xdefaults? При желании можно в:
~/.app-defaults/XTerm
~/.app-defaults/KFm
...
К примеру, gv _сохраняет_ свои настройки в ~/.gv
--
Yuriy Kaminskiy.
Valentin Nechayev
At 15-Feb-99 14:17, Sergey Kirpa wrote:
> Уже написали gdbm.
> Зачем ещё одну делать?
gdbm - хpанилище конфигов??? Да Вы, батенька, книг по выни обчитались ;;;)))
--
NN
Dmitry Povarov
Есть такая штука - LDAP ...
-Dizzy
------------------------------------------------------------------------
Dmitry "Dizzy" Povarov [ mailto:di...@glas.net ]
GlasNet System Development Team [ http://www.glasnet.ru/~dizzy ]
"Macavity, Macavity, there is no one like Macavity.
He's broken every human law, he breakes the law of gravity..." (T.Elioth)
Sergey Kirpa
Здравствуйте, уважаемый(ая) Valentin Nechayev!
─═─ Среда 17 февраля 1999г. 11:50, Valentin Nechayev писал(а) к Sergey Kirpa:
VN> Hello Sergey Kirpa!
VN> At 15-Feb-99 14:17, Sergey Kirpa wrote:
>> Уже написали gdbm.
>> Зачем ещё одну делать?
VN> gdbm - хpанилище конфигов??? Да Вы, батенька, книг по выни обчитались
VN> ;;;)))
Hе, я просто проанализировал приведенное ранее "ТЗ", и пришел к выводу, что
gdbm (и наверно ещё десяток других библиотек) ему
удовлетворяют. Так что делайте выводы сами.
Victor Wagner
YK> Hello, Alexei!
>>>>>> On 16:50 14/2/1999, de...@services.ru writes:
>>> Фиг. С комментариями у них проблемы. Лучше бы они воспользовались
>>> Xовыми ресурсами, благо Xrm при чтении .Xdefaults пользует cpp, со
>>> всеми вытекающими.
AD>> С комментариями да. Hо это мелочь по сравнению с остальным - можно
AD>> стараться давать понятные названия пунктам конфига. Да и исправить
AD>> они это планируют. А вот использовать .Xdefaults как _конфиг_
AD>> различных программ - IMHO было бы верхом идиотизма.
YK> Почему в ~/.Xdefaults? При желании можно в:
YK> ~/.app-defaults/XTerm
YK> ~/.app-defaults/KFm
YK> ...
YK> К примеру, gv _сохраняет_ свои настройки в ~/.gv
И система хороша тем, что, настройки вшитые в программу можно
переопределить
1. Hа уровне сайта в целом
/usr/lib/X11/app-defaults/app
2. Hа уровне юзера
в ~/.Xdefaults
К сожалению, деление на три уровня
сайт/юзер/конкретный дисплей соблюдается не столь строго, хотя по-моему
для этого все и было задумано.
Вообще говоря, ресурсы X умеют все, что умеет виндовый registry -
есть иерархия и есть данные разных типов. Hо плюс к тому учитывает
мультиюзерность и (отчасти) network transparency.
К сожалению, при всем при этом этот механизм обладает и (почти) всеми
недостатками registry, при отсутствии аналога regedit (editres не
предлагать).
Valentin Nechayev
At 17-Feb-99 12:19, Dmitry Povarov wrote:
> > gdbm - хpанилище конфигов??? Да Вы, батенька, книг по выни обчитались ;;;)))
>
> Есть такая штука - LDAP ...
Из пушки по воpобьям?
--
NN
Valentin Nechayev
At 17-Feb-99 13:47, Sergey Kirpa wrote:
>> Уже написали gdbm.
>> Зачем ещё одну делать?
VN> gdbm - хpанилище конфигов??? Да Вы, батенька, книг по выни обчитались
VN> ;;;)))
> Hе, я просто проанализировал приведенное ранее "ТЗ", и пришел к выводу, что
> gdbm (и наверно ещё десяток других библиотек) ему
> удовлетворяют. Так что делайте выводы сами.
Делаем выводы - ТЗ Вы поняли непpавильно. Если же считаете, что пpавильно -
действуйте - pедактиpуйте файл базы вpучную двоичным pедактоpом.
--
NN
Sergey Kirpa
Здравствуйте, уважаемый(ая) Valentin Nechayev!
─═─ Четверг 18 февраля 1999г. 11:00, Valentin Nechayev писал(а) к Sergey Kirpa:
VN> Hello Sergey Kirpa!
VN> At 17-Feb-99 13:47, Sergey Kirpa wrote:
>>> Уже написали gdbm.
>>> Зачем ещё одну делать?
VN>> gdbm - хpанилище конфигов??? Да Вы, батенька, книг по выни
VN>> обчитались ;;;)))
>> Hе, я просто проанализировал приведенное ранее "ТЗ", и пришел к
>> выводу, что gdbm (и наверно ещё десяток других библиотек)
>> ему удовлетворяют. Так что делайте выводы сами.
VN> Делаем выводы - ТЗ Вы поняли непpавильно. Если же считаете, что
Я понял его так как оно прозвучало. В нем нет пункта, в котором
говорится что конфиги должны быть удобны для редактирования
обычным текстовым редактором.
VN> пpавильно - действуйте - pедактиpуйте файл базы вpучную двоичным
VN> pедактоpом.
Здрасте. Я же не говорю, чтобы каждая база данных хранилась только
в виде текстовых файлов, чтобы их можно было поредактировать
вручную. Hужен компромисс. То, что предлагается вами - это собственно
компиляция конфигурационного файла в память, для облегчения работы с ним.
То есть, все равно доступ будет в двоичном виде, правда скрыто от
пользователя.
VN> --
VN> NN
VN> -+- ifmail v.2.14dev2
VN> + Origin: unknown (2:5020/400@fidonet)
Valentin Nechayev
At 18-Feb-99 13:48, Sergey Kirpa wrote:
>> Hе, я просто проанализировал приведенное ранее "ТЗ", и пришел к
>> выводу, что gdbm (и наверно ещё десяток других библиотек)
>> ему удовлетворяют. Так что делайте выводы сами.
VN> Делаем выводы - ТЗ Вы поняли непpавильно. Если же считаете, что
> Я понял его так как оно прозвучало. В нем нет пункта, в котором
> говорится что конфиги должны быть удобны для редактирования
> обычным текстовым редактором.
А это подpазумевается в понятии "конфиг". Все-таки ведь юникс, а не хpень
мастдайная.
VN> пpавильно - действуйте - pедактиpуйте файл базы вpучную двоичным
VN> pедактоpом.
> Здрасте. Я же не говорю, чтобы каждая база данных хранилась только
> в виде текстовых файлов, чтобы их можно было поредактировать
> вручную. Hужен компромисс. То, что предлагается вами - это собственно
> компиляция конфигурационного файла в память, для облегчения работы с ним.
> То есть, все равно доступ будет в двоичном виде, правда скрыто от
> пользователя.
А нафига тогда gdbm? В случае "скомпилиpованного" ваpианта есть значительно
более пpостые методы - основанные на последовательной записи.
--
NN
Victor Wagner
AV> From: Alexander Vorobiev <spa...@sparrow.diamant.ru>
AV> Все уже поняли, куда я клоню. Любая попытка придумать "библиотеку для
AV> разбора configов" рано или поздно приведет к проблеме создания некоего
AV> языка, причем чем дальше, тем все более изощренного. И эта проблема
AV> давным-давно решена (как и большинство проблем на свете). Extension
AV> languages (языки расширения) общего назначения существуют сто лет в
AV> обед. Tcl, guile - самые очевидные примеры. И нечего тут велосипед
AV> изобретать. Я уже слышу толпу, кричащую, зачем, мол, программе на 10
AV> кило, библиотека на 500? Ответ - дальше :)
Попробую возразить. Сначала оговорюсь, что точку зрения Александра я в
целом разделяю. Для программ выше определенного уровня сложности
необходим макроязык, и в качестве него надо брать либо Scheme, либо
Tcl. Perl и Python подходят меньше, но тоже подходят.
Лично я предпочитаю Tcl по следующим причинам:
1. меньше похоже на Lisp. Lot of impossibly silly parenthesis почему-то
многих пугает. Меня в том числе. Хотя приблизительно такое же количество
curly braces в C-шном или Tcl-евском коде воспринимается как само собой
разумеющееся. Я согласен, что это не более чем дело привычки но все же.
2. Больше подходит для интерактивной работы (т.е больше напоминает
традиционный подход "команда аргументы"). И путем умного определения
процедур, которые можно использовать в конфигах можно отчасти скрыть от
начинающего пользователя, что это язык. А кроме того, можно сделать в
программе окошко, где пользователь будет команды оного языка набирать.
Все-таки в сложных программах бывают вещи, которые проще сделать из
макро-языка, чем из менюшек. Тем более что есть готовая консоль с tab
completion, syntax highlighting и пр.
3. Реализаций Scheme много, а Tcl - один. И с лицензией у него все
в порядке (Berkley style). Со Scheme получается примерно то же, что
с javascript - язык вроде один и тот же, а в guile и scm есть некоторые
тонкие различия, на которые если не ты, то кто-то из твоих юзеров
обязательно наступит (с чего им вдруг взбредет в голову вкручивать scm
вместо guile - вопрос отдельный. Hо ведь придет)
4. Tcl это не только макроязык, но и hardware abstraction layer.
Если для работы с файловой системой, сокетами и графикой, использовать
его API, а не libc, то проблем с переносом в Windows и даже Macos не
будет.
5. Tcl Api содержит кучу полезностей, которые хороши и в чисто сишной
программе. Hапример - hash таблицы и пр.
Характерные пример - некоторые расширения Tcl (Expect и Oratcl например)
имеют опцию компиляции без Tcl, для использования в качестве сишных
библиотек.
Hо хватит тут заниматься пропагандой tcl. Я ведь собирался ругать
скриптовые языки вообще.
Во-первых, позволю себе не согласится с аргументом, что миримся же мы с
500К libc.so. Hе миримся. Hе знаю, кто как, а я catdoc иногда статически
компилю. Версию для DOS, например. В этом случае из libc берется только
то что действительно нужно, и программа получается размером 23К.
С интерпретатором Scheme или Tcl так не поступишь. Юзер волен написать
в конфиге такую конструкцию, которой автор и вообразить себе не мог, а
потом возмущаться почему под Linux (c динамической libguile) это
работает, а под AIX (со статически прилинкованной ее частью) - нет.
Я наступал на такие грабли при попытке грузить свои компилированные
расширения в статически слинкованный Tcl.
Во-вторых, вспоминая тот же catdoc, я его из принципа компилю для DOS
как 16-битное приложение. А то еще dpmi-сервер за собой такскать всего
лишь для того, чтобы вордовый файл прочитать. Увольте. А большая часть
скриптовых языков очень не любит быть 16-битными. Как раз Scheme тут вне
конкуренции. Hо я помню, как ко мне в гости приходил один любитель
Scheme чтобы собрать scm Watcom'ом. А то 16-битный вариант даже для
поиграться не годился. А ведь надо и для основной программы немного
памяти оставить.
Короче говоря, я хочу сказать, что программы бывают разного уровня
сложности, и на этих уровнях сложности количество ресурсов которое не
жалко пожертвовать на разбор конфигов, разное. Поэтому экологическая
ниша для простой библиотеки есть. Hо, как верно заметил Александр,
программы имеют свойство расти. Из чего следует очень забавный вывод -
библиотека должна быть такой, чтобы в определенный момент ее можно было
из программы выкинуть и заменить на интерпретатор Scheme или Tcl не
меняя ни конфигов, ни кода, который этим пользуется.
Путем, например, такого набора макросов:
#define cfgInit Tcl_CreateInterp
#define cfgParse(config,file) Tcl_EvalFile(config,file)
#define cfgGetString(config,name) Tcl_GetVar(config,name,TCL_GLOBAL_ONLY)
и так далее.
Victor Wagner
YK> Hello, Victor!
>>>>>> On 12:00 13/2/1999, Victor Wagner <2:5020/219.27> writes:
VW>> К тому же, yacc в linux это как правило bison, соответственно,
VW>> получаемый код это GPL. GPL, а не LGPL.
YK> Чушь. RFTM, да внимательнее. Полученный код - это _не_ GPL и даже не
YK> LGPL.
Именно его-то я и читал:
The output of the Bison utility--the Bison parser file--contains a
verbatim copy of a sizable piece of Bison, which is the code for the
`yyparse' function. (The actions from your grammar are inserted into
this function at one point, but the rest of the function is not
changed.) When we applied the GPL terms to the code for `yyparse',
the
effect was to restrict the use of Bison output to free software.
С тех пор поменяли, правда
As of Bison version 1.24, we have changed
the distribution terms for
`yyparse' to permit using Bison's output in non-free programs.
Formerly, Bison parsers could be used only in programs that were free
software.
VW>> А как это портировать, скажем в msdos?
YK> А что там надо портировать 8-0?
Попробуй, узнаешь.
VW>> И вообще, зачем программе в 300 строк парсер конфига на 500?
YK> 500 строк чего? Вывода bison+yacc? А ты думаешь, что _в коде_ это много
YK> больше, чем примитивный разборщик?
Думаю что да, ибо соответствие между количеством строк на C и
количеством команд на ассемблере для данного компилятора в данном
режиме оптимизации примерно константа.
YK> А по скорости работы? А по размеру кода? yacc-то по табличкам бегает.
А ты никогда не задумывался, почему GCC такой тормозной и такой
громоздкий, по сравнению со скажем, Free Pascal?
Именно потому, что на yacc/lex написан.
Dmitry Bely
> Dmitry Hodos <Dmitry...@p27.f1.n5004.z2.fidonet.org> wrote:
> DH> деятельности ;)). Почему уже второй человек высказывается в том духе, что
> DH> lex/yacc -- это монстры, и если уж чего на них парсить, так уж никак не
> DH> меньше, чем какой-нить SQL? Где эти таинственные расходы, из-за которых
>
> Потому что. Ты когда-нибудь смотрел в код, сгенерированный yacc?
> Я смотрел. После того как меня в bugtraq перед всем миром срамили за
> использование strcpy при разборе конфига (при этом buffer overflow могло
> теоретически возникнуть либо по инициативе запускающего юзера, либо по
> инициативе рута) я, пожалуй использовать код, для которого наличие
> неициализированных переменных нормально, не буду.
Да зачем вообще сдались все эти копытные? Есть же такая замечательная штука
- pccts. Он, правда, генерит С++, но, с моей точки зрения, это скорее плюс,
чем минус :-)
> К тому же, yacc в linux это как правило bison, соответственно,
> получаемый код это GPL. GPL, а не LGPL.
Неа.
[---cut---]
Conditions for Using Bison
**************************
As of Bison version 1.24, we have changed the distribution terms for
`yyparse' to permit using Bison's output in non-free programs.
Formerly, Bison parsers could be used only in programs that were free
software.
[---cut---]
> А как это портировать, скажем в msdos?
А в чем проблема, собственно?
> И вообще, зачем программе в 300 строк парсер конфига на 500?
>
> К тому же, есть у меня приятель который специалист по проектированию
> компиляторов. Так он при каждом моем упоминании yacc начинает брызгать
> слюной и материться. И действительно, парсер для одного и того же
> синтаксиса написанный по его рекомендациям на взаимно рекурсивных
> процедурах, получается раз в 10 компактнее чем на yacc. Т.е. код на C
> соизмерим по размерам с файлом .y.
>
> Причем речь идет не о вырожденных случаях типа конфигов, а о
> полномасштабыных арифметических выражениях.
>
> В общем, yacc это такой c-shell. С виду кажется удобным, а понимающими
> людьми "considered harmful".
Еще раз говорю - посмотри на PCCTS (ANTLR), http://www.antlr.org
и к тебе вернется вера в человечество. (Кстати, он public domain, т.е.
с лицензией проблем в принципе не возникает.) Когда мне понадобилось
сделать развесистый конфиг (текстовые/числовые переменые c C-like
операциями, операторы include, if/elsif/else, и прочее), я воспользовался
именно им. И что? Все радости жизни стоили всего 100 дополнительных кил
в бинари. И самое приятное, что сгенеренный текст поддается
прочтению/пониманию/отладке :-)
Hope to hear from you soon,
Dmitry
Eugene Dvurechenski
> сделать развесистый конфиг (текстовые/числовые переменые c C-like
> операциями, операторы include, if/elsif/else, и прочее), я воспользовался
> именно им. И что? Все радости жизни стоили всего 100 дополнительных кил
> в бинари. И самое приятное, что сгенеренный текст поддается
> прочтению/пониманию/отладке :-)
из этой серии можно рекомендовать и Python (embedded Python, если точно)
для любителей Modula-2 и Паскаля и tcl (тоже ембеддится) для фанатов
shell'а.
на мой вкус - Питон приятнее.
да и API довольно прост.
см. www.python.org и/или http://www.glasnet.ru/~jno/Python
--
SY, [ mailto:j...@glas.apc.org ]
jno (PRIVATE PERSON) [ http://www.glasnet.ru/~jno ]
a GlasNet techie [ http://www.aviation.ru/ ]
Alexander L. Belikoff
Dmitry Bely <db...@usa.net> writes:
> > Потому что. Ты когда-нибудь смотрел в код, сгенерированный yacc?
> > Я смотрел. После того как меня в bugtraq перед всем миром срамили за
> > использование strcpy при разборе конфига (при этом buffer overflow могло
> > теоретически возникнуть либо по инициативе запускающего юзера, либо по
> > инициативе рута) я, пожалуй использовать код, для которого наличие
> > неициализированных переменных нормально, не буду.
>
> Да зачем вообще сдались все эти копытные? Есть же такая замечательная штука
> - pccts. Он, правда, генерит С++, но, с моей точки зрения, это скорее плюс,
> чем минус :-)
Ну, тут совершенству нет предела - хватайте тогда уж сразу ANTLR и
генерите Жабу. А заодно и установите новый критерий GNU Software - всё
писать только на ней, на Жабе.
..Один из тех случаев, когда под цвет мебели подбираются дом, этаж,
город, да и страна, пожалуй...
c...@materials.kiev.ua
VW> А что такое стандарт de-facto? Это наличие реализации, которой все
VW> пользуются. Соответственно создание и некоторая раскрутка такой
VW> универсальной библиотеки и привела бы к появлению оного стандарта
VW> de-facto.
Дело в том, что таки с конфигами есть некие идеологические проблемы.
1) Конфиги делятся на read-only и application-editable
2) Конфиги бывают application-class (когда они ищутся в системных
каталогах, а потом в home-каталоге) и instance-class (когда цель
программы - прочитать _этот_ конфиг и выдать _для него_ результат.
И эти варианты трудно свести к одному. Hапример, readonly-конфиги удобно
прогонять через препроцессор (тогда сразу отпадает необходимость выбора
удобных для пользователя инвариантов: их можно определять defineами, да
и include - полезная фича; а m4 и арифметику умеет). А KDE-конфиги для моих
(instance-oriented) нужд в принципе не годятся, ибо:
1) Ищутся они где угодно, но не там, где мне надо.
2) Препроцессор к ним фиг прикрутишь (не нарушая идеологию и
совместимость).
Разборщик read-only конфигов (легко дополняемый) plain-C у меня
есть. Туп до ужаса: кушает пропущенный через /usr/bin/m4 (по умолчанию)
файл, отсеивая комментарии (#.*$), разбивает строку на [^:]+:[^#], левая
часть - имя, правая - значение, убирает leading и trailing spaces в
обеих частях и отрабатывает искейпинг `\' по правилам C. Мне хватает. Пример:
==========
include(`defaults.m4')dnl
define(`N',10)dnl
X: N
Y: N
Z: N
V: eval(N*N*N)dnl
dnl Зовем bc для вычислений с плавающей точкой
h: esyscmd(echo "scale=3 ; 1./N" | bc)dnl
dnl Задаем массив X[0..9]
forloop(`i',0,eval(N-1),`X[i] : eval(i*i)
')
Description : `Это пример конфига\nмоей счетной программы'
==========
Пример пользования -
CONFIG * cfg=conf_open("myfile.m4","-I../includes -DPROG=myprog");
X=conf_int(cfg,"X");
h=conf_dbl(cfg,"h");
for(i=0;i<X;i++){
x[i]=conf_dbl(cfg,conf_index1(cfg,"X",i));
}
desc=strdup(conf_str(cfg,"Description"));
conf_close(cfg);
Очевидно, это можно заворачивать в любую обертку (C++, default values,
default filenames, standard macros), писать изменяемые
данные в отдельный файл, который инклудить в основном конфиге, а в
application-режиме в пути поиска включать системные каталоги. Hо все
равно это мне не кажется универсальным подходом.
Тем более что если оставлять выбор препроцессора пользователю (что
разумно), т.е. ожидать имя препроцессора в первой строчке конфига
(например, после первого пробела, или после #!), то следующим шагом
будут выполняемые файлы (например, перловые скрипты в качестве конфигов
- чем плохо? [кроме того, что раз они выполняемые - значит, несекурные,
и вообще если geteuid()!=getuid() надо для паршенья делать
seteuid()...что не всегда возможно]).
VW> tin news and pine mail... Victor Wagner @ home =
--
Soiree,
Cyril.
: Удобнее оформлять часто совершаемую ошибку в виде библиотечной функции,
затем вызывать ее по мере необходимости.
Dmitry Bely
> > > Потому что. Ты когда-нибудь смотрел в код, сгенерированный yacc?
> > > Я смотрел. После того как меня в bugtraq перед всем миром срамили за
> > > использование strcpy при разборе конфига (при этом buffer overflow могло
> > > теоретически возникнуть либо по инициативе запускающего юзера, либо по
> > > инициативе рута) я, пожалуй использовать код, для которого наличие
> > > неициализированных переменных нормально, не буду.
> >
> > Да зачем вообще сдались все эти копытные? Есть же такая замечательная штука
> > - pccts. Он, правда, генерит С++, но, с моей точки зрения, это скорее плюс,
> > чем минус :-)
>
> Ну, тут совершенству нет предела - хватайте тогда уж сразу ANTLR и
> генерите Жабу.
PCCTS это и есть ANTLR. Версия 1.XX была написана на С (она поддерживается
до сих пор), а вот версия 2.X.X действительно написана на джаве. Но это не
мешает ей генерить C++ текст :-)
> А заодно и установите новый критерий GNU Software - всё
> писать только на ней, на Жабе.
>
> ..Один из тех случаев, когда под цвет мебели подбираются дом, этаж,
> город, да и страна, пожалуй...
Вот они, противники технического прогресса :-). Похоже, рассуждения г-на
Бутенки по поводу Exim vs Sendmail применимы и здесь. Речь не идет о Джаве
- ANTLR как C++ный генератор много лучше бизона/лекса.
Alexander L. Belikoff
> >>>>> En Sat, 13 Feb 99 12:03:31 +0200 Victor Wagner (VW) as ecrit:
>
>
> VW> А что такое стандарт de-facto? Это наличие реализации, которой все
> VW> пользуются. Соответственно создание и некоторая раскрутка такой
> VW> универсальной библиотеки и привела бы к появлению оного стандарта
> VW> de-facto.
>
> Дело в том, что таки с конфигами есть некие идеологические проблемы.
> 1) Конфиги делятся на read-only и application-editable
> 2) Конфиги бывают application-class (когда они ищутся в системных
> каталогах, а потом в home-каталоге) и instance-class (когда цель
> программы - прочитать _этот_ конфиг и выдать _для него_ результат.
>
А это совершенно ортогональные понятия: логика поиска конфиг-файлов,
заложенная в программе и синтаксис конфигов / методы их чтения
> И эти варианты трудно свести к одному. Hапример, readonly-конфиги удобно
> прогонять через препроцессор (тогда сразу отпадает необходимость выбора
> удобных для пользователя инвариантов: их можно определять defineами, да
> и include - полезная фича; а m4 и арифметику умеет). А KDE-конфиги для моих
То же самое, хотя и имеет отношение к библиотеке. Надо подумать об
определении интерфейса типа:
cfg_read(const char* fname, const char* cpp)
..который пропускал бы файл через п/проц. и читал бы вывод.
Alexei Dets
Yuriy Kaminskiy wrote:
>
> AD> они это планируют. А вот использовать .Xdefaults как _конфиг_
> AD> различных программ - IMHO было бы верхом идиотизма.
> ~/.app-defaults/KFm
А это совершенно перпендикулярно. Формат _неудобен_. И очень X-зависим.
Алексей
Victor Wagner
SK> Здравствуйте, уважаемый(ая) Valentin Nechayev!
SK> Hе, я просто проанализировал приведенное ранее "ТЗ", и пришел к выводу, что
SK> gdbm (и наверно ещё десяток других библиотек) ему
SK> удовлетворяют. Так что делайте выводы сами.
Видимо, из этого ТЗ выпала одна вещь, которая всеми остальными
участниками дискуссии подразумевалась по умолчанию и обсуждению не
подвергалась - возможность правки конфига текстовым редактором и любыми
утилитами обработки текста, в том числе и в single user mode.
По поводу утилит обработки текста, был у меня в свое время похаканный
adduser, который при копировании файлов из /etc/skel прописывал в них
на место специальной последовательности символов login и gecos.
Иногда очень удобно получалось. Hапример, для pinerc от DOS-овского
pine, который обитал в home-директории, а та шарилась по NFS как H:
SK> С наилучшими пожеланиями - Sergey.
--
--------------------------------------------------------
I have tin news and pine mail...
Victor Wagner @ home = vi...@wagner.rinet.ru
Vladimir Bormotov
Hi, Alexei!
>>>>> "AD" == Alexei Dets <de...@services.ru> writes:
>> AD> они это планируют. А вот использовать .Xdefaults как _конфиг_
>> AD> различных программ - IMHO было бы верхом идиотизма.
>> Почему в ~/.Xdefaults? При желании можно в: ~/.app-defaults/XTerm
>> ~/.app-defaults/KFm
AD> А это совершенно перпендикулярно. Формат _неудобен_. И очень
AD> X-зависим.
О! Hаконец-то я набрел на этот топик, который про конфиги...
Есть такая штука как libPropList
This file documents the libPropList library, hereafter referred to as
PL. The library uses an opaque data type to represent a tree structure
made of strings, data blocks, arrays and dictionaries (key-value pair
lists). This structure can be manipulated, written out to and read in
from a file, and synchronized with the contents of a file.
The purpose of PL is to closely mimick the behaviour of the property
lists used in GNUstep/OPENSTEP (there formed with the NSString,
NSData, NSArray and NSDictionary classes) and to be compatible with
it. PL enables programs that use configuration or preference files to
make these compatible with GNUstep/OPENSTEP's user defaults handling
mechanism, without needing to use Objective-C or GNUstep/OPENSTEP
themselves.
Берется на ftp.windowmaker.org/pub/libs/
--
Bor.
c...@materials.kiev.ua
>> Дело в том, что таки с конфигами есть некие идеологические проблемы.
>> 1) Конфиги делятся на read-only и application-editable
>> 2) Конфиги бывают application-class (когда они ищутся в системных
>> каталогах, а потом в home-каталоге) и instance-class (когда цель
>> программы - прочитать _этот_ конфиг и выдать _для него_ результат.
ALB> А это совершенно ортогональные понятия: логика поиска
ALB> конфиг-файлов, заложенная в программе и синтаксис конфигов /
ALB> методы их чтения
Безусловно. Только это не все понимают. Пример - в kde. Впрочем, они и
не задавались целью получить результат на все случаи жизни.
>> И эти варианты трудно свести к одному. Hапример, readonly-конфиги
>> удобно прогонять через препроцессор (тогда сразу отпадает
>> необходимость выбора удобных для пользователя инвариантов: их можно
>> определять defineами, да и include - полезная фича; а m4 и
>> арифметику умеет). А KDE-конфиги для моих
ALB> То же самое, хотя и имеет отношение к библиотеке. Hадо подумать об
ALB> определении интерфейса типа:
ALB> cfg_read(const char* fname, const char* cpp)
ALB> ..который пропускал бы файл через п/проц. и читал бы вывод.
Только вот писать их так прямо будет плохо: чревато полной потерей
исходного вида.
ALB> -- Alexander L. Belikoff Bloomberg L.P. / BFM Financial Research
--
Soiree,
Cyril.
: Old mail has arrived.