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

Так нельзя, а то не получится потроллить :}

Ты уже научил жсон валидировать себя и, (это важнее) кодекомплишну?

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

В таком деле конечному «пользователю» гораздо удобнее использовать конечные средства, чем рожать их самому.

Проблема созерцания простого конфига даже в виде XML несколько надумана. Простой конфиг выглядит в XML так же просто как и простой конфиг в каком нибудь ini. И абсолютно логично при таком раскладе пихать этот самый простой конфиг в какой-нибудь «реестр» — точку хранения с стандартным способом доступа.

Вот совсем другое дело, когда конфиг выглядит сложно. Тут появляется аж несколько альтернатив. Взять ёмбедед язык программиорвания, sh или lua например. Или родить самопал. Или взять страшный корявый XML. Разумеется, созерцать сложный XML конфиг радости мало, для созерцателей лучше использовать когломерат lua/sh/питон. Как потом с этой радостью работать другим - отдельный печальный вопрос.

К сожалению нет. Равно как и нет в «стандартном» линаксе средств для работы с ini,desktop,json и прочим хламом

Ручками

А чем же ещё? :3

JSON/YAML

Ну возможно YAML и более удобен (опять же это зависит от), но чем удобен JSON вне Java?

Тут появляется аж несколько альтернатив. Взять ёмбедед язык программиорвания, sh или lua например. Или родить самопал. Или взять страшный корявый XML. Разумеется, созерцать сложный XML конфиг радости мало, для созерцателей лучше использовать когломерат lua/sh/питон. Как потом с этой радостью работать другим - отдельный печальный вопрос.

Сам пугаешь, сам боишься.

Чо? То то в стандарте аяксописательства прокляли XML и дружно перешли на JSON.

Аякс это ЖаваСкрипт. JSON - это тупо структура в этом скрипте. Для JavaScript это оправдано, но не нужно тянуть этот JSON туда, где ему не место.

нет в «стандартном» линаксе средств для работы с ini,

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

Ну возможно YAML и более удобен (опять же это зависит от), но чем удобен JSON вне Java?

Всем тем же, чем и xml, но при этом он вполне человекочитаем. При этом, для него в том же пайтоне парсер есть в стандартной библиотеке, в отличие от YAML.

А можно поинтересоваться утилитой работы с ini в гну кори утилз?

Подскажи тогда уж парсеры для этих твоих .conf

diff/grep/cut/sed/cat etc etc etc.

Весь фрагмент громоздок.

странно - а помоему так совсем наоборот, а когда дохрена всего (зачастую лишнего) пихают в одну строчку - вот это громоздко

Еще раз: валидация есть? Если я напишу IOPCClasMatch - на какой стадии и кто отловит ошибку?

парсеру твое IOPCClasMatch - до лампочки, как написано - он так и передаст, а вот API (а конкретно - см. на кого эти параметры ссылаются "IOKitPersonalities"), не знает не про какой «IOPCClasMatch», а IOPCIClassMatch окажется «пустой» - что в этом случае произойдет (по работе данного драйвера) я не знаю, да и вообще параметр довольно специфичный - подробнее можно посмотреть тут

sed

Ну для XML что этот набор использовать мешает?

>sed
>ini-файл

А получится? С секциями то.

ini и на чистом sh просто парсить. Другой вопрос - костыльность этого решения

Еще раз: валидация есть? Если я напишу IOPCClasMatch - на какой стадии и кто отловит ошибку?

парсеру твое IOPCClasMatch - до лампочки

Оно твое, не мое. То, что парсеру «до лампочки», означает, что валидации у тебя нет. Твой XML-конфиг ничуть не лучше тупого ini.

http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml...

Тут про html, но суть та же.

для XML что этот набор использовать мешает?

Что покажет diff для двух файлов?

<a><b>42</b></a>

и

<a> 
<b>42</b> 
</a>

Что он должен показать?

Судя по проигнорированному варианту, у меня появился новый игнораст. Ну да ладно :}

$ diff -y /tmp/1.xml /tmp/2.xml 
<a><b>42</b></a>					      |	<a> 
							      >	<b>42</b> 
							      >	</a>

А что должен показать diff?

Т.е. ты хочешь сказать, что ini можно парсить регексами?

А что должен показать diff?

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

Т.е. ты хочешь сказать, что ini можно парсить регексами?

Нет, для ини тоже должна быть отдельная тулза.

Судя по проигнорированному варианту, у меня появился новый игнораст. Ну да ладно :}

Не обольщайся, может человеку просто лениво тщательно участвовать в срачике.

Т.е. ты хочешь сказать, что в случае

a=b
b=c

b=c
a=b

diff промолчит? Как интересно

для xml есть xmldiff, а что есть для ini?

Ну тогда на ещё: xmldiff. Хотя на самом деле я не знаю как он работает.

Нет конечно, это же разные данные и diff скажет нам об этом.

Пример лучше был выше по комментам.

он не чем не лучше, мой конкретный пример показывает текстовой вариант и графический, так вот - оно так сконструировано специально, чтобы пользователь не видел «тегов» - они от него скрыты, ему просто нужно заполнять поля и выставлять значения: String, Boolean, Number (integer), Date, Data + Dictonary и Array, ведь редактор намного лучше и точней сделает разметку - правильно?

Правда ты не сказал, что это такая реализация реестра, так бы стало понятнее, зачем оно там.

Так реестр по сути и содержит конфиги, но тут одно большое отличие - реестр вбирает их «в себя» и хранит все_это_добро в бинарном виде

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

ниче не понял....

WatchCat

Дело в том, что использовать xml, так как в Вашем примере, ващета моветон.

key и value никак не связаны, кроме как следованием одного за другим.

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

Ну так в чем же разница?

для xml есть xmldiff

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

а что есть для ini?

gnu coreutils.

И что ты хочешь этим сказать, мне интересно?

gnu coreutils.

ок, покажи все изменения в ini-файле, ес-но простая перестановка не должна показываться, как и комментарии и whitespace

>ему просто нужно заполнять поля и выставлять значения: String, Boolean, Number (integer), Date, Data + Dictonary и Array, ведь редактор намного лучше и точней сделает разметку - правильно?

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

Если все утилиты костыли и подпорки пиши без coreutils, а то это какие-то двойные стандарты.

У тебя дефицит внимательности что ли? Или как там называется заболевание, когда дети постоянно отвлекаются.

Напоминаю краткое содержание предыдущих серий:

0. Ты спросил чем отличаются два файла.

1. Я показал чем.

Ну, ты все перепутал. Давай я тебе напомню.

Тебе не понравился дифф двух XML, потому что «С точки зрения xml это два одинаковых дерева, поэтому корректный дифф-для-зумля не должен ничего показывать». С другой стороны тебя устраивает наличие диффа идентичных по этому критерию участков ini файла.

покажи все изменения в ini-файле, ес-но простая перестановка не должна показываться, как и комментарии и whitespace

Неразумные фонаты ХМЛ, у вас совсем уже мозги атрафировались, что примитивные вещи кажутся вам сложными, а может и недостижимыми?

как и комментарии и whitespace

Для вырезания комментариев используются sed

простая перестановка не должна показываться

для этого придумана утилита sort, которая ВНЕЗАПНО сортирует строки исходного файла, после чего порядок уже не имеет значения.

покажи все изменения в ini-файле

а вот для этого уже нужен diff.

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

Каке бредовые выводы ты делаешь, однако.

для этого придумана утилита sort, которая ВНЕЗАПНО сортирует строки исходного файла, после чего порядок уже не имеет значения.

Ну давай отсортируем ини файл с секциями

Прежде чем что-то поменять придётся «полюбоваться». В простых случаях, где XML выглядит хоть как-то читаемо, хватает обычных переменная=значение, а в сложных случаях XML-структуры могут разобрать разве что роботы, то есть человеки там лишние.

«ISO 8879:1986 Information processing — Text and office systems — Standard Generalized Markup Language (SGML)»,

Вот бы им и оставаться где-то в обработке текста.

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

наличие диффа идентичных по этому критерию

Глупый, кто тебе сказал, что они идентичны? Они разные и diff показывает где именно. Если ты не веришь мне, можешь перепроверить вывод diff на своём компьютере?

Кот бы говорил.

А это уже зависит от конкретного формата ини-файла-с-секциями.