URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID9
Нить номер: 8829
[ Назад ]

Исходное сообщение
"Идея создания утилиты x."

Отправлено Пророк , 13-Авг-10 21:47 
Хочу рассказать об идее утилиты командной строки.
Всем известно, что удобно использовать конвейеры из программ путем переназначения вывода с помощью |. В потоке обычно пересылается простой текст, который подходит для многих простых задач, но не более. В случае, когда нужно передать более сложные данные, хорошо подходит xml. Но xml вывод одной программы не будет пониматься другой программой, если они специально для этого не затачивались. Кое-что, конечно, можно стандартизировать, но не все.
Для того, чтобы одна программа понимала другую, как раз утилита, наиболее подходящим именем для которой будет x. Она будет брать xml вывод одной программы, и преобразовывать его в формат ввода другой программы, являсь между ними своего рода клеем.
Например:
program1 |x| program2

Сначала программа будет определять namespace для входного и выходного параметра, разбирая командную строку, либо взяв непосредственно из xml для входного потока (если он там указан), либо из свох ключей --from и --to.
Программа будет хранить в своих файлах правила XSLT/XQuery преобразования для каждой пары xml namespace, и использовать из. Всегда можно добавить еще одну пару namespace1 > namespace2 и шаблон, либо скачать уже созданный из репозитория. Для определения самих namespace из командной строки в файлах также будут содержатся простые правила их определения по имени программы и ее ключам.


Содержание

Сообщения в этом обсуждении
"Идея создания утилиты x."
Отправлено NuINu , 14-Авг-10 02:30 
KISS


"Идея создания утилиты x."
Отправлено Пророк , 16-Авг-10 22:55 
>KISS

Что показалось сложным? Как раз таки элементарно program1 |x| program2.


"Идея создания утилиты x."
Отправлено вуглускр , 16-Авг-10 11:33 
Мальчик прочитал книжку по XML/XSLT и вдохновился творить. Поверь, от XML-я больше проблем чем пользы.

"Идея создания утилиты x."
Отправлено Пророк , 16-Авг-10 23:23 
Т.е. не устраивает именно XML в качестве формата обмена данными? Нет проблем, тем более конечное решение все равно за автором программы. Пишите свои варианты, какой формат обмена данными по-вашему здесь подходит больше всего.

"Идея создания утилиты x."
Отправлено elvenic , 16-Авг-10 23:54 
>Т.е. не устраивает именно XML в качестве формата обмена данными? Нет проблем,
>тем более конечное решение все равно за автором программы. Пишите свои
>варианты, какой формат обмена данными по-вашему здесь подходит больше всего.

Ой, да не обращайте не них внимания.

Идея, если пока и не заслуживающая титула 'интересная', то по крайней мере 'любопытная'.

Можете написать быстренько прототип на Python, Ruby, Groovy, или чем еще таком-же легковесном? И пару примерчиков где это может быть полезно - скажем, одна программа выдает на выход XML в одной схеме, вторая читает в другой схеме, и репозитарий для утилиты 'x' с трансформацией (XSLT?) из одной схемы в другую. И некий текст зачем это все нужно. И выложите все это куда-то на github или sourceforge.



"Идея создания утилиты x."
Отправлено masted , 17-Авг-10 16:38 
Я бы тоже хотел увидеть прототип и страничку проекта.

"Идея создания утилиты x."
Отправлено вуглускр , 18-Авг-10 11:14 
>Т.е. не устраивает именно XML в качестве формата обмена данными?

Да. К слову, XSLT-трансформер принципиально не умеет обрабатывать данные в поточном режиме. То есть всё, что поступит на вход, надо будет распарсить в DOM, применить к нему трансформацию, а затем снова сгенерить XML.
Получаем, что таким пособом сколь-нибудь большие объёмы данных обработать будет невозможно.

> Нет проблем,
>тем более конечное решение все равно за автором программы. Пишите свои
>варианты, какой формат обмена данными по-вашему здесь подходит больше всего.

В каждом конкретном случае подходит свой формат. То есть твоя утилита "х" никому не нужна, потому что по необходимости на её месте будет стоять sed, awk, perl или вообще ничего.


"Идея создания утилиты x."
Отправлено Аноним , 03-Ноя-10 23:40 
> Да. К слову, XSLT-трансформер принципиально не умеет обрабатывать данные в поточном режиме.
> То есть всё, что поступит на вход, надо будет распарсить в
> DOM, применить к нему трансформацию, а затем снова сгенерить XML.
> Получаем, что таким пособом сколь-нибудь большие объёмы данных обработать будет невозможно.

XSLT не умеет, XPath умеет



"Идея создания утилиты x."
Отправлено Пророк , 16-Авг-10 23:33 
ADD: еще будет полезна утилитка или/и дополнительные ключи к сабжевой утилите, фильтрующую теги по XPath выражению. Например grepxml или что-то в этом роде. Она будет возвращать исходное дерево, содержащее только теги, совпадающие с выражением, и их родителей.

"Идея создания утилиты x."
Отправлено вуглускр , 18-Авг-10 11:15 
>ADD: еще будет полезна утилитка или/и дополнительные ключи к сабжевой утилите, фильтрующую
>теги по XPath выражению. Например grepxml или что-то в этом роде.
>Она будет возвращать исходное дерево, содержащее только теги, совпадающие с выражением,
>и их родителей.

Посмотри xmlstarlet, там это наверняка есть.


"Идея создания утилиты x."
Отправлено аноним , 17-Авг-10 04:18 
Феерический бред.

"Идея создания утилиты x."
Отправлено аноним , 17-Авг-10 20:28 
Т.е. комбайн-обертка над xsltproc с прикрученной коллекцией xslt'шек, чтоли?

Во-первых, не нужно потому что уродский xml обычно конвертят в нормальные бинарные форматы. А если уж нужно, то в виде одной xslt'шки и xsltproc. Комбайн втoпку.


"Идея создания утилиты x."
Отправлено Pahanivo , 17-Авг-10 21:44 
tool1 | x | tool2
1) сформировать хмл
2) выгрузить в конвеер (в хмл объем передачи возрастет в РАЗЫ!)
3) распарсить, перекроить из дного хмл в другой? во превых нахер нужен универсальный формат если его перекраивать? зачем перекраивать - может сразу уж написать выгруз в нужном формате? тем более что утилиты как я понял еще не существуют ))
4) потом в итоге снова распарсить?
простите, а не слишком ли ахуенный оверхед получается?

"Идея создания утилиты x."
Отправлено NuINu , 17-Авг-10 22:51 
могу раскрыть суть загадочного мистера х.
подставим вместо него известное значение perl, получим:

tool1 | perl | tool2
действительно универсалный перекодировщик )

таким образом задача состоит в том чтобы написать аналог перла


"Идея создания утилиты x."
Отправлено аноним , 18-Авг-10 00:02 
А потом:

perl | perl | perl

Сокращаем, получаем:

perl

Вывод: автор, убейся.


"Идея создания утилиты x."
Отправлено Pahanivo , 18-Авг-10 07:04 
>таким образом задача состоит в том чтобы написать аналог перла

жесть!!!!!!!!!!!


"Идея создания утилиты x."
Отправлено pavlinux , 30-Авг-10 03:45 
>Хочу рассказать об идее утилиты командной строки.

Автор, если нефига делать, напиши утилитку, а то мне впадлу

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.*
                            }
                }
    }
}

ну и так далее :)


"Идея создания утилиты x."
Отправлено ACCA , 05-Ноя-10 10:59 
Тот случай, когда ответ сложнее вопроса.

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

Да базара нет. Теперь немного арифметики для программ без ключей (!):
   для пары namespace1, namespace2 нужно два XSL - туда и сюда.
   для тройки namespace1, namespace2, namespace3 нужно 6 XSL
   для N namespaces нужно (сюрприз!) N^2-N XSL

Главный вопрос программиста - а не дохуя ли?

Это не считая других проблем.