Удаление строк по шаблону

xml

regexp

cat text | sed -e '/aaa/,/bbb/d'

Окей, тогда какой инструмент использовать?

По сути, есть XML файл, в котором много лишних блоков, что начинаются примерно так: <qwe asd="1" что-то ещё>, а кончаются на </qwe>.

И нужно удалить все блоки с asd="1", но не тронуть те, в которых asd="2" и все прочие. При этом блоки, что нужно оставить, тоже кончаются на </qwe>.

Filter by XPath? XSLT? Просто произвольная обработка твоим любимым неигрушечным ЯП?

Отличная идея, проблема в том, что мне всё это нужно выучить перед использованием.

Это не проблема, это банальная рабочая необходимость.

Вероятно можно решить при помощи комбинации jc и jq (преобразовать в JSON и отфильтровать средствами jq), но вероятно, что будет лишь раза в 1.5 проще, чем написать полноценный скрипт на каком-нибудь языке.

Когда-то много писал скриптов на Python для обработки XML, поэтому кажется несложным. На XSLT тоже писал, и XSLT явно будет сложнее, чем быстро накидать скрипт на Python.

Текстовые инструменты, не понимающие XML, скорее всего рано или поздно поломают файл, т.к. в XML whitespace ничего не значит, и он может быть отформатирован как угодно, хоть в одну строку.

Я готовый пример привёл, не подходит?

За cat | sed надо с работы гнать за профнепригодность.

За преждевременную оптимизацию надо с работы гнать за профнепригодность.

От перемены мест слагаемых сумма не меняется!

прочитать файл построчно, сформировать лист из всех строк. дальше просто работа с массивом. находишь ааа, создаешь другой лист в котором запомнишь все номера строк до той пока не встретится ббб. потом удаляем все строки с найдеными номерами и назад дамп в файл. по идее в таком случае «не трогать ббб если перед ними нет ааа» само собой разумеется потому что только ааа будет триггерить начало «запоминания».

Не совсем.

Да, да я уже решил проблему руками. Так было проще, мало данных.

Рубрика вредные советы продолжается.

Как ты представляешь себе xml -> json -> jq filter -> xml?

Вместо ну 5-7 строк на любимом ЯП.

Человек выше писал, что не умеет и не хочет программировать. Это единственное, что приходит в голову, если исключить программирование.

я уже решил проблему руками

Эх, не дочитал до этого места, взялся поиграть в эту игру )

SELECT xmlagg(u)::text
FROM (
	SELECT 
		UNNEST(
			(SELECT xpath('//doc/qwe', x)
				FROM (
					SELECT 
						$x$
						<doc>
							<qwe asd="2">
								<что-то другое="2"/>
							</qwe>
							<qwe asd="1">
								<что-то ещё="1"/>
							</qwe>
							<qwe asd="1">
								<что-то ещё="2"/>
							</qwe>
							<qwe asd="3">
								<что-то другое="3"/>
							</qwe>
						</doc>
						$x$::xml
									AS x
				) t
			)
		) u
) r
WHERE NOT xpath_exists($c$//qwe[@asd='1']$c$, u)

Нет, не экзамеционная задача, просто пытаюсь распарсить хитрый .xml файл с логами

Тут тебя на сайте уже лет 20 все видят, обычно таких и подозревают в попытке решить домашку на халяву)

Ну да, надо пару фрейверков притащить чтоб лишний кусок лога выкинуть

A jq он такой раз и осилил сразу. Нуну. Не говоря о всяких нюансах конвертации туда и обратно.

Там речь не про фреймворки, а про то, что cat часто используют не к месту.

cat foo | grep bar эквивалентно grep bar foo или grep bar < foo, только без лишнего вызова cat.

И чем плохо такое использование? Тем что можно без него? Ну так есть класс задач где плевать на расходы на вызов ката и пайп. Зато читаемее

Имхо, ты из мухи слона делаешь: увольнять я бы за такое точно не стал. Всегда можно ещё с оптимизировать, но станет ли от этого лучше, если довести сие стремление до абсолюта?

Я за это увольнять не призываю. Но если совсем докапываться, то часто вижу в скриптах что-то вида cat foo.txt | grep bar, что точно совершенно избыточно.

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

За обижание cat надо выгонять спать на коврик!

прочитать файл построчно, сформировать лист из всех строк.

Откровенно вредный совет. Так делать точно не надо. В оригинальной постановке задачи решение что делать с конкретной строкой легко принимается по мере их вычитывания. Это даже гораздо хуже чем cat | sed за которые выше обвиняли в проф-непригодности.

Текстовые инструменты, не понимающие XML, скорее всего рано или поздно поломают файл, т.к. в XML whitespace ничего не значит, и он может быть отформатирован как угодно, хоть в одну строку.

Не факт. В случаях когда мы сами же этот XML и создаём контролируя процесс, он становится не просто XML’ем а XML’ем отформатированным конкретным образом. И тогда использование текстовых инструментов становится вполне себе безопасным и уместным.

Текстовые инструменты, не понимающие XML, скорее всего рано или поздно поломают файл, т.к. в XML whitespace ничего не значит, и он может быть отформатирован как угодно, хоть в одну строку.

На этот случай есть xmllint --format.

Парсить строгий формат со схемой текстовыми инструментами путь в ад. Если xml прямо-таки необходим, то и инструменты нужны родные - xslt.

что в этом вредного? предложи как правильно.

зы: это без наезда. я не программист, но активно интересуюсь.

Парсить строгий формат со схемой текстовыми инструментами путь в ад.

Правила игры сильно меняются когда у вас терабайты XML файлов (условные логи) каждый длинной в сотни мегабайт..гигабайты, которые нужно шерстить быстро быстро (выгрызать записи соответствующие определенным критериям по запросу). Умрёте Вы их честно парсить. «Проверено электроникой».

А это ложное целеполагание. Такую уйню надо парсить 1 раз и удалять к уям)))

что в этом вредного?

O(N) space cost.

предложи как правильно.

Один enum’чик (конкретно здесь и bool’еана хватит) чтобы трекать текущее состояние (видели ‘aaa’, ждём ‘aaa’). Вычитали строчку, проверили / обновили если надо состояние, выплюнули или «подавили» строчку, след. итерация. Space-cost ограничен максимальной длиной строки в файле.

А это ложное целеполагание. Такую уйню надо парсить 1 раз и удалять к уям)))

Расскажите это регуляторам. Пример не с потолка взят. Часть таких логов нужно хранить с практической точки зрения пожизненно, и ещё гарантировать их неприкосновенность.

Тогда UPD. Парсить 1 раз, удалять к уям, сохранив схему, генерировать обратно при запросе регулятором. Работать с этим дерьмом - ни в коем случае.

UPD2. Кстати, генерация по схеме будет 100500 раз эффективнее выборки по схеме и шаблону.

UPD2. Кстати, генерация по схеме будет 100500 раз эффективнее выборки по схеме и шаблону.

Очень и очень спорное утверждение. Возможно Вы не до конца понимаете всех constraints того (подчеркну) практического случая о котором я говорю. (A) Вам нужно формировать эти логи с макс возможной скоростью (в реальности делается «ручками», как «text»), (B) Вы просто не имеете права их менять после того как они записаны, (C) схема постоянно меняется - часть атрибутов уходит (редко) и добавляются новые (часто), и возможные значения (очень часто), подавляющее число атрибутов - optional, (D) даже в пределах одного дня Вы имеете дело с несколькими слегка отличающимися схемами (в зависимости от конкретной версии модуля который их сгенерил), (E) счет instances идёт на десятки тысяч.

Что именно Вы собираетесь использовать как «final storage format» после парсинга? Что бы Вы не предложили - будут «те же яйца вид сбоку». XML далеко не худший вариант. Можно было бы использовать что нибудь покомпактнее, но оно было бы не так operator friendly (часто приходится смотреть «глазками» и разбирать «ручками»).

ПыСы. Мы сильно отдалились от вопроса который ТС задал. Всё что я пытаюсь донести - processing of XML как текста имеет право на жизнь. Конкретно мне решение с sed предложенное выше нравится больше всего. Плюс я так понял что ТС свою проблему уже порешал. Ну, и учитывая его репутацию (добрейшей души человек, прыгает на амбразуру постоянно - я бы так не смог), давайте завяжем этот офтоп? Тяпница к тому же ;) Дзинь ;)

Привязка конкретных схем к конкретным данным в нормальном формате дает оверхед в виде одного INT. Что все еще привлекательнее и быстрее.

По остальному дзынь, поддерживаю))

При помощи SAX парсера можно довольно быстро и эффективно это делать.

XSLT - довольно непростой инструмент. На мой взгляд, учитывая, что XML давно ушёл в прошлое и используется больше по инерции, тратить время и усилия на его изучение - напрасный труд. Никогда больше не пригодится.