https://slinkov.ru/openforum/vsluhforumID9/8829.html Хочу рассказать об идее утилиты командной строки.<br>Всем известно, что удобно использовать конвейеры из программ путем переназначения вывода с помощью &#124;. В потоке обычно пересылается простой текст, который подходит для многих простых задач, но не более. В случае, когда нужно передать более сложные данные, хорошо подходит xml. Но xml вывод одной программы не будет пониматься другой программой, если они специально для этого не затачивались. Кое-что, конечно, можно стандартизировать, но не все.<br>Для того, чтобы одна программа понимала другую, как раз утилита, наиболее подходящим именем для которой будет x. Она будет брать xml вывод одной программы, и преобразовывать его в формат ввода другой программы, являсь между ними своего рода клеем. <br>Например:<br>program1 &#124;x&#124; program2<br><br>Сначала программа будет определять namespace для входного и выходного параметра, разбирая командную строку, либо взяв непосредственно из xml для входного потока (если он там указан), либо из свох ключей --from и --to.<br>Програм https://slinkov.ru/openforum/vsluhforumID9/8829.html#18 Fri, 05 Nov 2010 07:59:35 GMT Тот случай, когда ответ сложнее вопроса.<br><br>&gt; xml namespace, и использовать из. Всегда можно добавить еще одну пару<br>&gt; namespace1 &gt; namespace2 и шаблон, либо скачать уже созданный из репозитория.<br>&gt; Для определения самих namespace из командной строки в файлах также будут<br>&gt; содержатся простые правила их определения по имени программы и ее ключам.<br><br>Да базара нет. Теперь немного арифметики для программ без ключей (!):<br> для пары namespace1, namespace2 нужно два XSL - туда и сюда.<br> для тройки namespace1, namespace2, namespace3 нужно 6 XSL<br> для N namespaces нужно (сюрприз!) N^2-N XSL<br><br>Главный вопрос программиста - а не дохуя ли?<br><br>Это не считая других проблем.<br> https://slinkov.ru/openforum/vsluhforumID9/8829.html#17 Wed, 03 Nov 2010 20:40:07 GMT &gt; Да. К слову, XSLT-трансформер принципиально не умеет обрабатывать данные в поточном режиме.<br>&gt; То есть всё, что поступит на вход, надо будет распарсить в<br>&gt; DOM, применить к нему трансформацию, а затем снова сгенерить XML.<br>&gt; Получаем, что таким пособом сколь-нибудь большие объёмы данных обработать будет невозможно.<br><br>XSLT не умеет, XPath умеет<br><br><br><br><br> https://slinkov.ru/openforum/vsluhforumID9/8829.html#16 Sun, 29 Aug 2010 23:45:40 GMT &gt;Хочу рассказать об идее утилиты командной строки. <br><br>Автор, если нефига делать, напиши утилитку, а то мне впадлу <br><br>sysctl в зависимости от текущего ядра, и иерархическое распарсивание, а то достало ужо...<br><br>То есть, новый sysctl должен понимать как старый sysctl.conf, так и новый, с тегами. <br><br>@UNIQ 2 {<br> # тут все параметры для ядер от 2.0.0 до 2.*<br><br> @UNIQ 2.4 <br> {<br> # тут только для 2.4.+ <br> }<br><br> @UNIQ 2.6<br> {<br> # тут только для 2.6.+ <br><br> @UNIQ 2.6.6-16 <br> {<br> # тут только для 2.6.6.* до 2.6.16.*<br><br> @UNIQ 2.6.16.25-61 <br> {<br> # тут только для 2.6.16.25 до 2.6.16.61<br> }<br><br> }<br><br> @UNIQ 2.6.16,18,26 <br> {<br> # тут только для 2.6.16.*, 2.6.18.* и 2.6.26.* <br> }<br> @UNIQ 2.6.32-34,36 <br> {<br> # тут только для 2.6.32.*, 2.6.33.*, 2.6.34.* и 2.6.36.* <br> https://slinkov.ru/openforum/vsluhforumID9/8829.html#15 Wed, 18 Aug 2010 07:15:41 GMT &gt;ADD: еще будет полезна утилитка или/и дополнительные ключи к сабжевой утилите, фильтрующую <br>&gt;теги по XPath выражению. Например grepxml или что-то в этом роде. <br>&gt;Она будет возвращать исходное дерево, содержащее только теги, совпадающие с выражением, <br>&gt;и их родителей. <br><br>Посмотри xmlstarlet, там это наверняка есть.<br> https://slinkov.ru/openforum/vsluhforumID9/8829.html#14 Wed, 18 Aug 2010 07:14:51 GMT &gt;Т.е. не устраивает именно XML в качестве формата обмена данными?<br><br>Да. К слову, XSLT-трансформер принципиально не умеет обрабатывать данные в поточном режиме. То есть всё, что поступит на вход, надо будет распарсить в DOM, применить к нему трансформацию, а затем снова сгенерить XML.<br>Получаем, что таким пособом сколь-нибудь большие объёмы данных обработать будет невозможно.<br><br>&gt; Нет проблем, <br>&gt;тем более конечное решение все равно за автором программы. Пишите свои <br>&gt;варианты, какой формат обмена данными по-вашему здесь подходит больше всего. <br><br>В каждом конкретном случае подходит свой формат. То есть твоя утилита "х" никому не нужна, потому что по необходимости на её месте будет стоять sed, awk, perl или вообще ничего.<br> https://slinkov.ru/openforum/vsluhforumID9/8829.html#13 Wed, 18 Aug 2010 03:04:06 GMT &gt;таким образом задача состоит в том чтобы написать аналог перла <br><br>жесть!!!!!!!!!!!<br><br> https://slinkov.ru/openforum/vsluhforumID9/8829.html#12 Tue, 17 Aug 2010 20:02:06 GMT А потом:<br><br>perl &#124; perl &#124; perl<br><br>Сокращаем, получаем:<br><br>perl<br><br>Вывод: автор, убейся.<br> https://slinkov.ru/openforum/vsluhforumID9/8829.html#11 Tue, 17 Aug 2010 18:51:29 GMT могу раскрыть суть загадочного мистера х.<br>подставим вместо него известное значение perl, получим:<br><br>tool1 &#124; perl &#124; tool2<br>действительно универсалный перекодировщик )<br><br>таким образом задача состоит в том чтобы написать аналог перла<br> https://slinkov.ru/openforum/vsluhforumID9/8829.html#10 Tue, 17 Aug 2010 17:44:58 GMT tool1 &#124; x &#124; tool2<br>1) сформировать хмл<br>2) выгрузить в конвеер (в хмл объем передачи возрастет в РАЗЫ!)<br>3) распарсить, перекроить из дного хмл в другой? во превых нахер нужен универсальный формат если его перекраивать? зачем перекраивать - может сразу уж написать выгруз в нужном формате? тем более что утилиты как я понял еще не существуют ))<br>4) потом в итоге снова распарсить?<br>простите, а не слишком ли ахуенный оверхед получается?<br>