На конференции администраторов крупных систем LISA (Usenix Large Installation System Administration) два исследователя Дартмутского университета выступили (http://www.itworld.com/software/231515/usenix-dartmouth-expa...) с идеей создания расширенных вариантов утилит diff и grep для обработки сложных типов данных. В настоящее время утилиты ещё на находятся на этапе создания работающих прототипов, доступен только восьмистраничный документ (http://www.cs.dartmouth.edu/reports/TR2011-705.pdf) с подробным описанием сути проекта. Код будет открыт после завершения разработки. Работа ведётся при финансировании от компании Google и Министерства энергетики США.
Развиваемые в рамках проекта контекстно независимый вариант утилиты Grep (bgrep) и иерархический Diff (bdiff), ориентированы на разбор синтаксических блоков кода, вместо манипулирования однострочными записями. Таким образом bdiff и bgrep могут оперировать частями файлов конфигураций, логов и других наборов данны...URL: http://www.itworld.com/software/231515/usenix-dartmouth-expa...
Новость: http://www.opennet.me/opennews/art.shtml?num=32513
давно пора, в общем-то - построчные текстовые форматы много где умерли, а для массы распространенных случаев (вроде ini того же) можно сделать дабольно простые универсальные инструменты
Где ты в никсах видел ini-файлы? Текстовые файлы нигде не умерли, кроме твоего больного виндозного воображения. Виндоз головного мозга - как звучит!
Samba, mySql, openssl, git ... то что у них расширение не .ini не меняет формат.
>Samba, mySql, openssl, git ... то что у них расширение не .ini не меняет формат.Вы так пишете как будто примитивный общий формат конфигурационных файлов сразу же подразумевает .ini . Дотфайлы, не ?
>>Samba, mySql, openssl, git ... то что у них расширение не .ini не меняет формат.
> Вы так пишете как будто примитивный общий формат конфигурационных файлов сразу же
> подразумевает .ini . Дотфайлы, не ?Да при чём тут дотфайлы... А этот формат и впрямь называется ini-style.
> Вы так пишете как будто примитивный общий формат конфигурационных файлов сразу же подразумевает .iniВпервые он начал широко использоваться именно в INI.
> Дотфайлы, не ?
Дотфайлы - это такие файлы, которые не выводятся в ls без добавления -a. Не обязательно, чтобы это были конфиги.
Напротив, много где умерли нетекстовые форматы.
> Напротив, много где умерли нетекстовые форматы.Речь шла не о текстовых форматах вообще, а о построчных текстовых форматах.
> Напротив, много где умерли нетекстовые форматы.Ага, на OSM сперва ушиблись и стали делать карту в XML. А когда карта планеты стали 250Гб - обосрались кирпичами и сделали бинарный формат. Тем более что редактировать такую XMLину все-равно малореально. А бинарный формат зато весит лишь 14 Гб для той же карты. Такая вот незначительная разница. Всего почти в 20 раз :)
XML вообще уродливый костыль костылей. Не зря вон МежДелМаш производит аппаратные XML-акселераторы за сотни тысяч денег. Как-то при объемах ширпотребовских усб-винтов по три тера и таких же масштабах данных, XML тихо слился... Ну-кося, попарси многопроходно XML-файло объемчиком 1 терабайтик всего... Что, выкуси? Ай, не выходит каменный цветок, Данила-мастер!
Для кода такие тулзы были бы весьма полезны, а то сделаешь форматирование или коммментарий добавишь и сидишь, в патчах разбираешься, какое изменение существенно, какое - нет.
на форматирование помогает ключик -w :)
форматирование не всегда ограничевается расстановкой пробелов ;)
При разбиении длиной строки на несколько, или, наоборот, при слиянии - не очень он помогает :). Ну и изменения в комментариях тоже не всегда хочется видеть.
Успехов конечно авторам, но я думаю что это невозможно, будет слишком сложно и не надёжно этим пользоваться.
> будет слишком сложно и не надёжно этим пользоваться.Да не парьтесь, сейчас весь софт такой
Даже если и будет сложно пользоваться, быстрее будет один раз разобраться и экономить кучу времени, чем каждый раз вручную делать.
А не надо пытаться обработать все мыслимые случаи - простыми вариантами (к примеру, в которых можно задать правила для выделения элементов, тип элемента и фокусы вроде вхождения) можно перекрыть очень многое. Считай, нечто наподобие селекторов CSS с задаваемыми пользователями элементами. Плюс зашить несколько вариантов (json, xml bin-style...), а в идеале сделать определения формата подгружаемыми.
Почему LISA, если правильно ULISA?
Нет, Usenix — это конференция.
как только не извращаются люди, лишь бы не принимать какой-нибудь унифицированный текстовый формат описания данных, вроде JSON или какого-нибудь варианта S-expressions.
> как только не извращаются люди, лишь бы не принимать какой-нибудь унифицированный текстовый
> формат описания данных, вроде JSON или какого-нибудь варианта S-expressions.Ну переставит вам какая-нибудь софтина строки в JSONе - сами же извиняться к авторам bdiff побежите :)
>> как только не извращаются люди, лишь бы не принимать какой-нибудь унифицированный текстовый
>> формат описания данных, вроде JSON или какого-нибудь варианта S-expressions.
> Ну переставит вам какая-нибудь софтина строки в JSONе - сами же извиняться
> к авторам bdiff побежите :)Пошлем-ка мы такую софтину в /dev/null по-быстрому, пока никто не видел.
> как только не извращаются люди, лишь бы не принимать какой-нибудь унифицированный текстовый
> формат описания данных, вроде JSON или какого-нибудь варианта S-expressions.Как раз таки про него вспомнил. Как народ смотрит на то, что бы конфиги были в джейсоне?
У бинда конфиг уже напоминает джейсон. Как насчет логов? Было бы достаточно просто представить их в виде объектов и парсить не регулярками... Тьху где то я это уже видел, ну его к черту, sed, grep, awk наше все. Лучшее - враг хорошего.
у бинда конфиг перл стайл, си стайл, но никак не json
Я вам напомню одно большое ограничение JSON в этом плане - в нем нет комментариев
http://ru.wikipedia.org/wiki/JSON#.D0.A1.D1.80.D0.B0.D0.B2.D...
Вы уверены?
> http://ru.wikipedia.org/wiki/JSON#.D0.A1.D1.80.D0.B0.D0.B2.D...
> Вы уверены?Уверен: http://json.org/
Хотя никто не мешает сделать парсер с поддержкой комментариевОтвет автора стандарта: http://tech.groups.yahoo.com/group/json/message/152
Джейсон - неудобный формат для писания руками. Слишком много кавычек, не прощает простейшие ошибки (вроде запятой после последнего элемента объекта или массива), отсутствие комментариев уже упоминали...В итое гимеем ного ругани на синтаксис. Знаю, что говорю - у нас в крпном проекте конфигурация на json - многовато мороки с ним.
потому что JSON гогно. А действительно "унифицированные форматы описания данных" (тм) (это xml и т.п.) давно используют, но лучше жить от этого всё равно не стало
они не человекочитаемые и очень тяжелые
это смотря как писать, xml можно использовать вполне няшно. Кроме xml есть другие вариации, yaml например.
> они не человекочитаемые и очень тяжелыеJSON тоже.
Слижком сложно все будет, а почему бы не внести предложение все конфиги хранить в xml к примеру...
> Слижком сложно все будет, а почему бы не внести предложение
> все конфиги хранить в xml к примеру...Прошу прощение за оффтопик, но XML...
Конфиг - это API между человеком и программой, а не между программами.
К сожалению многие об этом уже забыли.
Программисты - не занимаются форсмажорными ситуациями.
exWinAdmins - не имеют понятия, какую гибкость даёт текстовый конфиг по сравнению с GUI.
> exWinAdminsпочему ex ?
> Слижком сложно все будет, а почему бы не внести предложение
> все конфиги хранить в xml к примеру...Так потом разницу между XML обычным diff и не посмотреть, о чем и новость собственно.
P.S. Собсно это одна из многих причин, по которой XML должен умереть, но это тема для срача, а не для новости
>> Слижком сложно все будет, а почему бы не внести предложение
>> все конфиги хранить в xml к примеру...Как и отметили, это не для людей.
https://lh4.googleusercontent.com/-30fhF6xRNf4/Ttub-IyL1RI/A...
> Так потом разницу между XML обычным diff и не посмотреть, о чем
> и новость собственно.Попадался на глаза xmldiff, но так уже и не помню -- дошло до него или проще обошлись...
> P.S. Собсно это одна из многих причин, по которой XML должен умереть,
> но это тема для срача, а не для новостиДа пускай себе живёт, только бы не пытались его скотчем примотать ко всему подряд, невзирая на осмысленность.
Посмотреть. Это даже тривиальная, в современных реалиях, задача. Вот только, парсинг требуется. Хотя, это не проблема при сравнении конфигов, размер которых вряд-ли превысит мегабайт.
Проблема с ХМЛ другая — менее удобно для человека
Не думаю, что сабж будет сильно популярен. Преимущество теплых ламповых grep/diff/sed в простоте (один раз научился пользоваться - никогда не забудешь) и универсальности (пригождаются очень часто, а когда есть хорошие инструменты для работы с текстом, решения проблем сами собой приходят в голову)
> Не думаю, что сабж будет сильно популярен. Преимущество теплых ламповых grep/diff/sed в
> простоте (один раз научился пользоваться - никогда не забудешь) и универсальности
> (пригождаются очень часто, а когда есть хорошие инструменты для работы с
> текстом, решения проблем сами собой приходят в голову)Ковровые бомбардировки квадратноколесными велосипедами вообще повсеместно вошли в моду - введены разными малоадекватными потрясателями основ. Достаточно посмотреть на всяческие замены syslogd, или устоявшегося за десятиления разбиения директорий... Одно да потому, снова и снова. И сотни дистров.
И все это гогно выдается за типа развитие.
> Преимущество теплых ламповых grep/diff/sed в простоте [...] и универсальностиСм. тж. "full exploitation": http://lwn.net/Articles/411845/
>> Преимущество теплых ламповых grep/diff/sed в простоте [...] и универсальности
> См. тж. "full exploitation": http://lwn.net/Articles/411845/Нифига они не универсальны, постоянно приходится извращаться с grep'ом многострочных форматов. Последний раз сочинял скрипт для grep'анья вывода "multipath -l"
Если в результате проекта можно будет легко grep'ать такое, без наколеночного костыля, будет класно.
>>> Преимущество теплых ламповых grep/diff/sed в простоте [...] и универсальности
>> См. тж. "full exploitation": http://lwn.net/Articles/411845/
> Нифига они не универсальны, постоянно приходится извращаться с grep'ом
> многострочных форматов.Вы, может, немного не поняли. Кофе они тоже не варят, но вот multiline regex умеют. :) (хотя иногда и впрямь проще разобрать | while read line; do case "$line" in ... и понеслась с выставлением флажков, угу -- если не разводить скрипты на sed/awk/perl/$etc)
Ровно также выучите один язык задания правил поиска тегов - и вперёд. И хоть xml, хоть json,хотьещё что - у ваших ног. Вплоть до бинарных форматов, кстати, если разумно описать. Регэкспы же как-то освоили? А эта штука попроще будет.При этом учтите, что на все основные форматы правила парсинга напишут за вас, вам останется только задавать что-то наподобие CSS селекторов - где именно смотреть или выкусывать хотите. Так что для подавляющего большинства случаев вообще всё примитивно будет.
Давно пора. Очень не хватает. Надеюсь, эти фичи быстро интегрируют и с популярным текстовыми редакорами и IDE.
