XML-парсер мог бы проверять, что имена параметров указаны правильно, их типы совпадают и значения находятся в заданных пределах. Это «пыль»?

Давай проверим

 Option      "XkbOptions" "grp:cps_toggle,grp_led;caps"

Имена параметра указаны верно. Типы совпадают. Значения в указанных пределах. А всё вместе: абсолютно некорректный конфиг. Наверное и вправду пыль.

Тут просто кто-то ...

Итак, вместо того чтобы признать свою ошибку оппонент решил тупо заболтать тему. Почему я не удивлён?

Если ты считаешь, что это нормально обработать только часть возможных конфигов в каком-либо формате

Форматов ini-файлов много разных. За исключением тривиальных случаев у каждой программы --- свой. Естественно, обработчики под каждый формат пишутся отдельно. gnu coreutils и posix shell позволяет сделать это элементарно.

Бгг. Я тебе там сслыки кинул, посмотри что ли.

Вспомни, с чего тред начался, угу.

Захожу я в ~/.kde/share/config 

Проблемы пионеров-кедерастов меня абсолютно не интересуют.

>Форматов ini-файлов много разных.
Ну, давай. Сколько?

>у каждой программы --- свой
>обработчики под каждый формат пишутся отдельно
Убивать.

>gnu coreutils и posix shell позволяет сделать это элементарно.
Оно и видно :}

Проблемы игнорирующих реальность нас, поверь, тоже абсолютно не интересуют :3

Вспомни, с чего тред начался, угу.

С того, что ты спросил почему нельзя использовать гнутые текстовые утилиты для работы с xml. Кажется тут я тебе уже всё объяснил.

Гну коре утилс помогут и парсить XML. На том же уровне, что и ини. Примерно.

Ты опять не прочитал мой пост. Может быть ты его потерял? Давай я тебе еще раз дам ссылочки:

Зачем хранить конф файлы в XML ?! (комментарий) Зачем хранить конф файлы в XML ?! (комментарий)

Ну, давай. Сколько?

Не считал.

Убивать.

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

Т.е. по факту сказать нечего. Отлично. Следующий :3

Проблемы игнорирующих реальность

/home/ugoday% ls .kde
ls: невозможно получить доступ к .kde: Нет такого файла или каталога

А я живу в другой реальности.

У тебя удивительная манера вбрасывать реплики вместо нормального общения.

Ну да, у тебя нет KDE поэтому в ini файлов не бывает секций. Да ты что?! :3

А что, нужны? [obj] key1 = val принципиально ничем не отличается от obj.key1 = val Вопрос лишь в том как использовать, xml в этом плане хуже (кто в obj key1=val key2=val, кто в obj>key1>val</key1</key, кто-то лишь часть в атрибуты пихает, в общем кто во что горазд. а людям потом в этом говне разбирайся) в итоге все конфиги говно, но ини хотя бы человекочитаемое, в отличии от json/xml. а не говна вроде как и нету, в итоге каждый выбирает то говно что ближе ему

Ты вообще националист, я ж молчу. Oh, wait :}

Это круто до тех пор, пока у тебя вложенность не превышает нескольких секций с говорящими именами

Сколько раз ты этот «obj.» напишешь? Ну, вперёд и с песней, но ini уже такой, какой есть, и предлагать распарсить только часть формата может только больной человек.

у тебя нет KDE поэтому в ini файлов не бывает секций.

Кто сказал, что не бывает? Назови имя этого человека.

С другой стороны

форматы, которые тут считаются «более добрыми», на самом деле являются таковыми только по причине специфичной интерпретации некоторых символов (\n, пробел, реже табуляция) некоторыми средствами обработки(терминалы и их эмуляторы, ориентированные на них текстовые редакторы, олдскульные принтеры). Вполне очевидно, что для данных других типов (не «последовательность букв для печати») оптимальными являются другие форматы и средства обработки. Соответственно, сравнивать эти форматы без привязки к соответствующим средствам нужно весьма осторожно.

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

Т.е. ты сознательно предлагаешь парсить только такие ini файлы, которые есть на твоём компьютере и удовлетворяют условию «нет секций»? Всё ещё хуже, чем мне казалось.

пока у тебя вложенность не превышает нескольких секций с говорящими именами

Наличие многих вложенных секций с говорящими именами говорит о хреновой архитектуре ваших конфигов. Должно быть xml провоцирует разводить помойку вместо того чтобы подумать и сделать всё аккуратно.

ты сознательно предлагаешь парсить только такие ini файлы

Где? Ну вот где ты такое прочитал?

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

Это говорит только о сложности структур сериализованных данных, не более чем

Вы хотели сказать, что у ненужного XML есть одно огромное ненужное преимущество? Тонко...

Т.е. не предлагаешь? Значит парсить ini файлы таким способом нельзя и ты лгал.

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

Почему «не положено» и «сверх меры»? XML изначально разрабатывался для описания валидируемых форматов. Какой вообще смысл использовать XML в режиме тупого ini?

нет ну а причем тут парсер - конечно оно там както все увязано, до того что CF - указывает на CoreFoundation, NS - на Cocoa API, IO - на IOKit, и каждый свое место знает воспринимает и подхватывает, валидировать то оно валидирует, но как бы через «другие органы» (и как я понимаю не абы как попало а через связующие нити - те через API, а скорее всего - оно само частью API и является, но не как в win32 - утрамбованное и сверху присыпанное, а вполне отделимое и спокойно заменяемое при необходимости), а XML - как структура..

/вообщем тут уже надо подробнее разбирать что/куда

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

Ок. Я тут причем? Я вообще за реестр для простых конфигов )

сложности структур сериализованных данных

Напоминаю, мы говорим о конфигурационных файлах. То, что xml можно применять для сериализации/десериализации между программами не оспаривается.

А сколько лишних тегов ты напишешь в xml?

Т.е. ты говоришь про так сказать простые конфиги? Да, там я тоже не очень за чистый XML. Я там за реестр, с похрен каким бекендом и схемами :D

Значит парсить ini файлы таким способом нельзя

Ну вот, опять ты за меня какую-то хрень додумал. :-( Я тебе не мешаю тут с собой общаться?

Я вообще за реестр

Сказал бы сразу, что ты поганый извращенец, я бы на тебя время не тратил.

Ну, давай, скажи :}

: cat 1.ini
MainWindow.d="diogupdoigdoj"
MainWindow.main-graphics-module.x=2
MainWindow.main-graphics-module.y=2
MainWindow.main-graphics-module.z=199

: cat 1.xml
<MainWindow>
        <d>diogupdoigdoj</d>
        <main-graphics-module>
                <x>1</x>
                <y>2</y>
                <z>1999</z>
        </main-graphics-module>
</MainWindow>

: du --bytes 1.*
139     1.ini
134     1.xml

В оригинале использованы табы, но ЛОР их не любит.

Так скажи, можно ли парсить произвольный ini файл coreutils'ами или нет? Если «да», то ты лжёшь, если «нет», то об чём спор, зачем вклинивался?

А какая-нить библиотеке сделает тебе 1kb в хрен пойми каком формате т схему до кучи пихнет(ты о ней не забыл в своем примере?)

Какая ещё библиотека пихнёт? У тебя какой-то особенный уличный парсер XML?

можно ли парсить произвольный ini файл coreutils'ами

Можно. Posix shell тьюринг полный.

Однако решать вопрос в терминах теоретической осуществимости чего-либо не интересно. Практики рассуждают в терминах:

а) удобно ли распарсить данный конкретный конфиг;

б) как сделать данный конфиг наиболее удобным для обработки.

Так вот. Я утверждаю, что:

а) для подавляющего большинства программ можно придумать такой конфиг, который удобно бы обрабатывался средствами coreutils;

б) конфиги подавляющего большинства реальных программ удобно обрабатываются с помощью coreutils.

Для особо одарённых уточняю, что я ни в коем случае не утверждаю, что простых ini файлов будет достаточно для любых программ и что всегда и везде coreutils будут оптимальными инструментами. Это совсем не так. Впрочем, в сложных случаях и этого вашего зумля будет также не достаточно.

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

ну как не надо? если мне нужно чтонибудь изменить /или/ добавить - все равно от этого никуда не деться..

я уверен - яблы попробовали «по всякому», но вот решили почему то что так удобней - и я с ними солидарен в этом плане, ниразу никаких проблем или непоняток при работе с .plist не возникало (даже достаточно здоровенных по объему)..

да и вообще - все сильно зависит от задачи, есть к примеру FictionBook, и там тоже «не так как у вас» - в примере (и тоже понятно почему)..

>Posix shell
>coreutils
До ну?

>для подавляющего большинства программ можно придумать такой конфиг
Не нужно 100500 разных форматов конфигов. Их и так уже достаточно

>конфиги подавляющего большинства реальных программ удобно обрабатываются с помощью coreutils

Да да, KDE нереальная программа, и гномореестр тоже, угу. И конфиги fontconfig.

>Для особо одарённых уточняю, что я ни в коем случае не утверждаю, что простых ini файлов будет достаточно для любых программ
А я тебя не об этом спрашиваю. Разговор там шёл о том, что, де, xml парсить кореутилсами также хорошо, как и ini — никак.

Эээ… тьфу, в примеры затесались XML конфиги.

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

>если мне нужно чтонибудь изменить /или/ добавить - все равно от этого никуда не деться
Что? Зачем тебе чтобы записать 1 нужно писать integer? Программа, в общем-то, сама знает, что она там ждёт. Взять чтение с обычных текстовых конфигов — там всё текстом хранится и ничего, никто не умер.

И что это за такая магическая библиотека, которая тебе всё пихает и пихает? Давай уже, удиви. Может стоит взять библиотеку, которая ничего не пихает?

До ну?

Ну, вот, опять ты вбасываешь и я должен догадываться что ты хочешь этим сказать. Да ну нафиг.

Не нужно 100500 разных форматов конфигов.

Мне изобилие и богатство выбора не мешают.

KDE нереальная программа,

И для него тоже можно придумать нормальные конфиги. И вместо гномореестра тоже.

И конфиги fontconfig.

МЕРЗОСТЬ! МЕРЗОСТЬ! СУЧЬЯ МЕРЗОСТЬ!

xml парсить кореутилсами также хорошо, как и ini — никак.

Т.е. из посылки «можно придумать такой формат ini файла, который было бы не удобно обрабатывать средствами coreutils», ты сделал вывод «ini нельзя парсить coreutils». Всё-таки мозг иксэмэльщиков поражён чем-то тяжёлым.

JSON такая же лапша, даже ещё хуже, чем XML.

чем же хуже? много лучше