Хочу рассказать об идее утилиты командной строки.
Всем известно, что удобно использовать конвейеры из программ путем переназначения вывода с помощью |. В потоке обычно пересылается простой текст, который подходит для многих простых задач, но не более. В случае, когда нужно передать более сложные данные, хорошо подходит xml. Но xml вывод одной программы не будет пониматься другой программой, если они специально для этого не затачивались. Кое-что, конечно, можно стандартизировать, но не все.
Для того, чтобы одна программа понимала другую, как раз утилита, наиболее подходящим именем для которой будет x. Она будет брать xml вывод одной программы, и преобразовывать его в формат ввода другой программы, являсь между ними своего рода клеем.
Например:
program1 |x| program2Сначала программа будет определять namespace для входного и выходного параметра, разбирая командную строку, либо взяв непосредственно из xml для входного потока (если он там указан), либо из свох ключей --from и --to.
Программа будет хранить в своих файлах правила XSLT/XQuery преобразования для каждой пары xml namespace, и использовать из. Всегда можно добавить еще одну пару namespace1 > namespace2 и шаблон, либо скачать уже созданный из репозитория. Для определения самих namespace из командной строки в файлах также будут содержатся простые правила их определения по имени программы и ее ключам.
KISS
>KISSЧто показалось сложным? Как раз таки элементарно program1 |x| program2.
Мальчик прочитал книжку по XML/XSLT и вдохновился творить. Поверь, от XML-я больше проблем чем пользы.
Т.е. не устраивает именно XML в качестве формата обмена данными? Нет проблем, тем более конечное решение все равно за автором программы. Пишите свои варианты, какой формат обмена данными по-вашему здесь подходит больше всего.
>Т.е. не устраивает именно XML в качестве формата обмена данными? Нет проблем,
>тем более конечное решение все равно за автором программы. Пишите свои
>варианты, какой формат обмена данными по-вашему здесь подходит больше всего.Ой, да не обращайте не них внимания.
Идея, если пока и не заслуживающая титула 'интересная', то по крайней мере 'любопытная'.
Можете написать быстренько прототип на Python, Ruby, Groovy, или чем еще таком-же легковесном? И пару примерчиков где это может быть полезно - скажем, одна программа выдает на выход XML в одной схеме, вторая читает в другой схеме, и репозитарий для утилиты 'x' с трансформацией (XSLT?) из одной схемы в другую. И некий текст зачем это все нужно. И выложите все это куда-то на github или sourceforge.
Я бы тоже хотел увидеть прототип и страничку проекта.
>Т.е. не устраивает именно XML в качестве формата обмена данными?Да. К слову, XSLT-трансформер принципиально не умеет обрабатывать данные в поточном режиме. То есть всё, что поступит на вход, надо будет распарсить в DOM, применить к нему трансформацию, а затем снова сгенерить XML.
Получаем, что таким пособом сколь-нибудь большие объёмы данных обработать будет невозможно.> Нет проблем,
>тем более конечное решение все равно за автором программы. Пишите свои
>варианты, какой формат обмена данными по-вашему здесь подходит больше всего.В каждом конкретном случае подходит свой формат. То есть твоя утилита "х" никому не нужна, потому что по необходимости на её месте будет стоять sed, awk, perl или вообще ничего.
> Да. К слову, XSLT-трансформер принципиально не умеет обрабатывать данные в поточном режиме.
> То есть всё, что поступит на вход, надо будет распарсить в
> DOM, применить к нему трансформацию, а затем снова сгенерить XML.
> Получаем, что таким пособом сколь-нибудь большие объёмы данных обработать будет невозможно.XSLT не умеет, XPath умеет
ADD: еще будет полезна утилитка или/и дополнительные ключи к сабжевой утилите, фильтрующую теги по XPath выражению. Например grepxml или что-то в этом роде. Она будет возвращать исходное дерево, содержащее только теги, совпадающие с выражением, и их родителей.
>ADD: еще будет полезна утилитка или/и дополнительные ключи к сабжевой утилите, фильтрующую
>теги по XPath выражению. Например grepxml или что-то в этом роде.
>Она будет возвращать исходное дерево, содержащее только теги, совпадающие с выражением,
>и их родителей.Посмотри xmlstarlet, там это наверняка есть.
Феерический бред.
Т.е. комбайн-обертка над xsltproc с прикрученной коллекцией xslt'шек, чтоли?Во-первых, не нужно потому что уродский xml обычно конвертят в нормальные бинарные форматы. А если уж нужно, то в виде одной xslt'шки и xsltproc. Комбайн втoпку.
tool1 | x | tool2
1) сформировать хмл
2) выгрузить в конвеер (в хмл объем передачи возрастет в РАЗЫ!)
3) распарсить, перекроить из дного хмл в другой? во превых нахер нужен универсальный формат если его перекраивать? зачем перекраивать - может сразу уж написать выгруз в нужном формате? тем более что утилиты как я понял еще не существуют ))
4) потом в итоге снова распарсить?
простите, а не слишком ли ахуенный оверхед получается?
могу раскрыть суть загадочного мистера х.
подставим вместо него известное значение perl, получим:tool1 | perl | tool2
действительно универсалный перекодировщик )таким образом задача состоит в том чтобы написать аналог перла
А потом:perl | perl | perl
Сокращаем, получаем:
perl
Вывод: автор, убейся.
>таким образом задача состоит в том чтобы написать аналог перлажесть!!!!!!!!!!!
>Хочу рассказать об идее утилиты командной строки.Автор, если нефига делать, напиши утилитку, а то мне впадлу
sysctl в зависимости от текущего ядра, и иерархическое распарсивание, а то достало ужо...
То есть, новый sysctl должен понимать как старый sysctl.conf, так и новый, с тегами.
@UNIQ 2 {
# тут все параметры для ядер от 2.0.0 до 2.*@UNIQ 2.4
{
# тут только для 2.4.+
}@UNIQ 2.6
{
# тут только для 2.6.+@UNIQ 2.6.6-16
{
# тут только для 2.6.6.* до 2.6.16.*@UNIQ 2.6.16.25-61
{
# тут только для 2.6.16.25 до 2.6.16.61
}}
@UNIQ 2.6.16,18,26
{
# тут только для 2.6.16.*, 2.6.18.* и 2.6.26.*
}
@UNIQ 2.6.32-34,36
{
# тут только для 2.6.32.*, 2.6.33.*, 2.6.34.* и 2.6.36.*
}
}
}
1. Тэги начинающиеся с @UNIQ N { всегда должны обрабатываться как уникальные, т.е.@UNIQ 2.0 {
# все ядра 2.0.*@UNIQ1.3.21-vasyapup1.9.98 {
# и вдруг захотелось 1.3.21-vasyapup1.9.98}
# а тут продолжили оптять для 2.0.*
}
2. Теэги начинающееся с "@GROUP N {" и "@SUBGROUP N {" - есть групповые. Т.е.@GROUP 2 {
# все ядра 2.*
@SUBGROUP 2 {# все ядра 2.2.*
@SUBGROUP 6 {
# все ядра 2.2.6.*
}}
@SUBGROUP 6 {
# все ядра 2.6.*
@SUBGROUP 16-32 {
# все ядра 2.6.16.* до 2.6.32.*
}
}
}3. Тэги начинающиеся с @VERSION, @PATCHLEVEL, @SUBLEVEL, @EXTRAVERSION - абсолютные.
Т.е. возможны варианты
@UNIQ 2.0.15 {
# только 2.0.*
@SUBLEVEL 22 {
# только ядра 2.0.22.*
}@PATCHLEVEL 4 {
# только ядра 2.4.15.*
@PATCHLEVEL 6 {
# только ядра 2.6.15.*
}}
@SUBGROUP 0 {
# опять 2.0.*
@SUBGROUP 6 {
# все ядра 2.2.6.*
}}
}} # 1.3
Приоритеты:Самый высший - @UNIQ
Далее - @VERSION, @PATCHLEVEL, @SUBLEVEL, @EXTRAVERSION, которые просто заменяют число в соответствующей позиции.
низший приоритеты - @GRUOP и @SUBGROUP - которые дописывают в конец нумерации своё значение.отдельно можно создать секцию @COMMON { } - для всех, без исключения, но с отрицаниями.
@COMMON {
от 0 до ....
!@VERSION 1 {
# кроме 1.*
}!@VERSION 2 {
кроме 2.*
!@SUBGROUP 1,3 {
# кроме 2.1.* и 2.3.*
!@SUBLEVEL 5 {
# и 2.5.*
}
}
}
}ну и так далее :)
Тот случай, когда ответ сложнее вопроса.> xml namespace, и использовать из. Всегда можно добавить еще одну пару
> namespace1 > namespace2 и шаблон, либо скачать уже созданный из репозитория.
> Для определения самих namespace из командной строки в файлах также будут
> содержатся простые правила их определения по имени программы и ее ключам.Да базара нет. Теперь немного арифметики для программ без ключей (!):
для пары namespace1, namespace2 нужно два XSL - туда и сюда.
для тройки namespace1, namespace2, namespace3 нужно 6 XSL
для N namespaces нужно (сюрприз!) N^2-N XSLГлавный вопрос программиста - а не дохуя ли?
Это не считая других проблем.