Простые регулярные выражения

0. vasilev2015 1847 30.04.18 12:56 Сейчас в теме
Шпаргалка к экзамену "Эксперт по технологическим вопросам".

Перейти к публикации

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. tormozit 5919 01.05.18 07:30 Сейчас в теме
Это точно для 1сников? =)
Уж очень сложно и неудобно.
2. vasilev2015 1847 01.05.18 09:12 Сейчас в теме
(1) Здравствуйте, Сергей ! Когда я смотрел другие статьи про регулярные выражения, где упор делается на использование perl, у меня возникал тот же вопрос. Постарался упростить ))).

Регулярные выражения примечательны тем, что позволяют парсить файлы технологического журнала общим объемом порядка 100 Гигабайт за время порядка 5 минут. Других таких инструментов нет. ЦУП медленнее на порядки.

P.S. Пользуюсь инструментами разработчика каждый день. Спасибо Вам.
3. tormozit 5919 01.05.18 13:14 Сейчас в теме
(2) Кажется обычно более разумно настроить фильтр записи журнала (logcfg.xml), чтобы он собирал то, что нужно. А не собирать в 10-100 раз больше логовов, чем нужно, неоправдано нагружая сервер и вынуждая себя пользоваться в разы менее удобными инструментами. В анализе техножурнала (ИР) непосредственно при чтении логов сейчас доступен только отбор по дате и он уже в большинстве случаев в разы ускоряет загрузку логов. Планирую туда же добавить фильтр по типу события (на этапе чтения). Он позволит еще ускорить логов в ряде случаев. Но конечно с выборкой описанной в статье анализ техножурнала (ИР) не сравнится по скорости.
starik-2005; ivanov660; Spartacus; +3 Ответить
4. vasilev2015 1847 01.05.18 13:26 Сейчас в теме
(3) Да, согласен. Поэтому позиционирую статью не как инструменты парсинга ТЖ, а как шпаргалку к экзамену. С нетерпением ждем улучшений ИР. :-))
5. palsergeich 01.05.18 20:37 Сейчас в теме
(3)
(2) Кажется обычно более разумно настроить фильтр записи журнала (logcfg.xml), чтобы он собирал то, что нужно. А не собирать в 10-100 раз больше логовов, чем нужно, неоправдано нагружая сервер и вынуждая себя пользоваться в разы менее удобными инструментами. В анализе техножурнала (ИР) непосредственно при чтении логов сейчас доступен только отбор по дате и он уже в большинстве случаев в разы ускоряет загрузку логов. Планирую туда же добавить фильтр по типу события (на этапе чтения). Он позволит еще ускорить логов в ряде случаев. Но конечно с выборкой описанной в статье анализ техножурнала (ИР) не сравнится по скорости.

Иногда, особенно когда не знаешь почему все работает медленно, надо собрать всё, убрать главные проблемы, и после этого уже работать с ограниченным ТЖ.
Ваш инструмент, я пользовался в том числе и им, в нем действительно удобно сводить данные, но для первичного анализа - regex, ибо в ИР к сожалению уже на 200+ тыс записях (точное число не скажу) вылетает, а клеить анализ за каждые 5 минут - не вариант.
Очень простой пример. На прошлой неделе разбирал один ТЖ, там, помимо тех проблем о которых я догадывался, за час из сервера приложений было больше полумиллиона вызовов НайтиПоКоду в цикле в регламентном задании. С фильтром на длительность эту проблему обнаружить не удастся. НайтиПоКоду вынесен за цикл, стало сразу лучше.
6. tormozit 5919 01.05.18 21:18 Сейчас в теме
(5) Частые и одновременно легкие запросы, создающие в сумме большую нагрузку, эффективнее всего ловить через новый инструмент "Статистика запросов MSSQL", который использует не требующую включения и не создающую нагрузки статистику по запросам из процедурного кэша MSSQL. После обнаружения такого запроса в статистике MSSQL человек уже настраивает фильтр в техножурнале по тексту оператора SQL (имеется соответствующая команда в окне "Конвертор текста СУБД") и далее анализирует собранный техножурнал для выявления отправляющих этот запрос контекстов встроенного языка. Сразу через техножурнал выявлять такие запросы в разы менее непродуктивно.
mvxyz; palsergeich; +2 Ответить
8. headMade 143 02.05.18 09:19 Сейчас в теме
(6) а что это за инструмент такой "Статистика запросов MSSQL". Где про него можно прочитать подробнее ?
9. tormozit 5919 02.05.18 13:07 Сейчас в теме
(8)
Статистика

Инструмент "Статистика по запросам MSSQL" появился в последней выпущенной версии и пока не имеет страницы с описанием. Она появится в ближайшее время. Как искать инструмент по названию, показано на картинке
Прикрепленные файлы:
Spartacus; CSiER; fancy; palsergeich; headMade; +5 Ответить
12. tormozit 5919 02.05.18 16:25 Сейчас в теме
(8) Добавил описание на основном сайте
26. Dach 296 04.05.18 10:17 Сейчас в теме
(12) Извините за оффтоп, но раз уж тут пошла речь...

Если в конфигурацию не встроена обработка ирАнализТехноЖурнала - отчет сбора статистики не запускается.

Имею ввиду из портативной версии ИР.

Пришлось найти все вхождения и закомментить:

ПриКомпоновкеРезультата(
......

АнализТехножурнала = Обработки.ирАнализТехножурнала.Создать();
29. tormozit 5919 04.05.18 20:10 Сейчас в теме
(26) Было бы классно увидеть багрепорт там, где все ожидают его увидеть и подробно оформленный. Проблему воспроизвел.
11. palsergeich 02.05.18 13:48 Сейчас в теме
7. tormozit 5919 01.05.18 21:27 Сейчас в теме
(5)
в ИР к сожалению уже на 200+ тыс записях (точное число не скажу) вылетает

1. Для предотвращения вылетов в 32-разрядном приложении можно использовать ограничитель по количеству загружаемых событий.
2. Можно использовать 64-разрядное клиентское приложение, где такой проблемы, полагаю, не должно быть (не проверял тщательно).
10. palsergeich 02.05.18 13:41 Сейчас в теме
(7)
в ИР к сожалению уже на 200+ тыс записях (точное число не скажу) вылетает

1. Для предотвращения вылетов в 32-разрядном приложении можно использовать ограничитель по количеству загружаемых событий.
2. Можно использовать 64-разрядное клиентское приложение, где такой проблемы, полагаю, не должно быть (не проверял тщательно).

1) Знаю, но даже 500 000 это мало. Пример совершенно реальной проблемы - я привел выше, можно бесконечно сидеть и делать оптимизацию в запросах дольше 0.1 секунды (чем ранее коллеги и занимались) пытаться оптимизировать, а толку будет мало.
2) Версию клиента посмотрю, может быть и правда проблема была в версии клиента у меня и x86 и x64 стоят, спасибо за наводку.
14. sanjakaiser 03.05.18 12:21 Сейчас в теме
Еще по этой теме есть вебинар на три часа от Виктора Богачева (экзаменатор, принимающий Эксперта). Гуглить например так: регулярные выражения Богачев
15. starik-2005 2180 03.05.18 12:32 Сейчас в теме
(0)
Вообще, любое количество символов в регулярных выражениях означается «.*», но создателей команды cat это не смущает.
Ну тут автор попутал маску файла и шаблон регулярного выражения. Автор, не нужно путать эти два в общем-то неодинаковых по синтаксису "языка".
[0-9][0-9]:.{15,20}
Ну как вариант, хотя, конечно, "\d{2}:.{,20}" на мой взгляд выглядит лаконичнее и нагляднее, да и вообще я сомневаюсь, что "{15,20}" даже в обрезанном варианте здесь нужно - достаточно использовать нежадный модификатор.

Если бы я не знал, что такое регулярные выражения, то вряд ли я с помощью данной статьи в них смог бы разобраться. Да, это очень простой и эффективный инструмент, просто необходимо разобраться в его элементах с несколькими кейсами. В этой статье кейсы есть, а теоретической части нет (да, она, конечно, выходит за рамки статьи, но т.к. занимает мало, то могли бы и включить).

По-сути, регулярные выражения очень хорошо позволяют извлекать текст из текста и модифицировать текст, что зачастую даже важнее поиска (по поводу простого сравнения с шаблоном по регулярке, то в 1С есть механизм XDTO, который может с этим справиться на любой поддерживаемой ОС без внешних компонент). А вот менять он не умеет. При том простой кейс замены даты, выгруженной в обычном формате 1С (ДД-ММ-ГГГГ чч:мм) можно поменять на XML-формат (YYYY-MM-DD) с помощью групп вот таким образом:
Шаблон поиска:
>(\d\d).(\d\d).(\d{4})( \d\d:\d\d)<

Шаблон замены:
>\3-\2-\1<

Т.е. определяются группы (то. что в скобках). Дальше эти группы по номеру используются в шаблоне замены, в итоге сначала выводится 3-я группа с годом, потом вторая, потом первая. Таких шаблончиков разобрать штук десять - и все, регулярки освоены. Дальше можно делать с ними все на свете.
17. vasilev2015 1847 03.05.18 12:46 Сейчас в теме
(15) Про регулярные выражения лучше прочитать в книге Джеффри Фридла «Регулярные выражения». В статье - приложение на практике, приближенное к экзамену.
18. starik-2005 2180 03.05.18 12:52 Сейчас в теме
(17)
Про регулярные выражения лучше прочитать в книге
Вы читали в книге? Как оно там? Сколько страничек? Если читали, то зачем пишите "[0-9]" вместо "\d"?

На мой взгляд, сначала лучше в ВИКИ читнуть, поиграться с notepad++, потом с grep (кстати, никогда не юзал egrep - чем он отличается?), потом с sed. В итоге за пару дней освоится основной функционал, которого уже будет для большинства задач за глаза. А дальше, если хочется стать экспертом не только в 1С, а еще и в регулярных выражениях, можно перейти к книгам (но я бы, лично, из книг порекомендовал "Бытие и Время", а то все хотят стать экспертами, а зачем - не знают )))
19. vasilev2015 1847 03.05.18 12:59 Сейчас в теме
(18) да, читал. Использую [0-9] вместо "\d" поскольку [0-9] работает там, где иногда не работает "\d". Egrep равносилен grep с ключом -e. Экспертом хочу стать по-приколу: могу себе позволить.
20. starik-2005 2180 03.05.18 16:17 Сейчас в теме
(19) в вики написано, что это одно и то же, только синтаксис регулярок упрощен, а для полного нужно заэкранировать спецсимволы.

Интересно стало, где "[0-9]" работает, а "\d" - нет... Сходу не смог ничего такого придумать. Подскажете?
21. leemuar 03.05.18 18:17 Сейчас в теме
(20) Насколько я помню \d не является метасимволом в posix, только в pcre. Шанс нарваться сегодня на утилиту, не умеющую pcre довольно мал.

За написание [0-9] вместо \d есть большой аргумент: удобочитаемость. Регулярки очень сложно читать. Помнить и расшифровывать все метасимволы достаточно неудобно. Использование простого диапазона повышает "понимаемость" регулярки.

А так, конечно, разницы в получаемом результате нет
Darklight; +1 Ответить
16. kudlach 22 03.05.18 12:42 Сейчас в теме
Извиняюсь, но термин "регулярные выражения" - это немного не к журналу регистрации изначально. Это к стыку мат.анализа , теории множеств и азам программирования.
Отдельная тема к экзаменам второго курса ВУЗа.
Думается мне, более правильно тема звучала бы "Применение регулярных выражений в решении задач таких-то"
22. mvxyz 258 03.05.18 21:47 Сейчас в теме
(16) Нормальное название статьи. Тем кто готовится к экзамену на эксперта сразу понятно о чем речь. Автору спасибо.
23. starik-2005 2180 03.05.18 22:28 Сейчас в теме
(22)
За написание [0-9] вместо \d есть большой аргумент: удобочитаемость. Регулярки очень сложно читать. Помнить и расшифровывать все метасимволы достаточно неудобно. Использование простого диапазона повышает "понимаемость" регулярки.
А мне, лично, кажется, что короче - в данном конкретном случае лучше. Я тут видел в XBRL ЦБ таких регулярок в шаблоны наклал, что страшно становится. Например, они написали полное выражения для корректного диапазона дат (при том для текстового элемента открытой оси). И вот этот огород в двести символов (а может и больше) определенным образом напрягает. Они там все феврали вырисовали с учетом високосных лет, например. И все это мельтешит через "|" и цифры.
24. sanjakaiser 04.05.18 07:31 Сейчас в теме
К сожалению, отредактировать предыдущий мой пост уже нельзя, вот видео Богачева

https://www.youtube.com/watch?v=pV8wgI8haf4.

(Не реклама) Автор дает представление о том, что такое регулярки, почему их надо использовать при анализе ТЖ, ну и на практике показывает, куда это запрягать + Это тот человек, который принимает у вас экзамен 1С:Эксперт
Rustig; Grigoripal; +2 Ответить
25. vasilev2015 1847 04.05.18 08:56 Сейчас в теме
(24) спасибо, полезная информация.
27. Dach 296 04.05.18 10:22 Сейчас в теме
Пользуясь случаем (простите за оффтоп еще раз), раз в ветке отметились мастера разбора ТЖ, хочу посоветоваться...

Есть большая БД, РИБ. Я верно понимаю, что если настраивать ТЖ, то это придется делать во всех узлах и потом выполнять некий сводный анализ? Втом числе, наверное и с помощью регулярок.

И еще момент... Мы встроили в конфу БСП и подсистему "Оценка производительности". Планируем выявить самые "нехорошие места" сначала ей, а потом, как мне кажется - можно уже и ТЖ более детально настроить... Может кто-то пользовался подсистемой? Поделитесь впечатлениями, плз.
28. vasilev2015 1847 04.05.18 12:32 Сейчас в теме
(27) я не очень мастер, но поскольку ветка моя - постараюсь ответить. Если у вас есть планы парсить, проводить анализ и искать узкие места в дочерних базах, то настраивайте там ТЖ. Если нет планов - "впрок" не делайте. Обязательно следите за местом, которое потребляет ТЖ.

Оценка производительности незаменима для общения с заказчиком: у вас апдекс был 0,6 а теперь 0,85 - извольте заплатить. Для себя апдекс тоже интересен: смотреть, что операторы проводят заказы по 59 секунд и удивляться их терпению. Или постфактум обосновать полезность приобретения нового raid. Менеджеры привыкли верить цифрам и красивым графикам.
30. lustin 05.05.18 02:19 Сейчас в теме
я конечно понимаю что регулярные выражения это просто - но точно не для 1С-ников. А вот ниже регулярки уже для них.

#Использовать verbal-expressions

// Проверим корректность формирования URL. Допустимые схемы - http[s] и ftp

ЭкранироватьПереданноеЗначение = Ложь;

ВербальноеВыражение = Новый ВербальноеВыражение()
    .НачалоСтроки()
    .Затем(
        Новый ВербальноеВыражение()
            .Найти("http")
            .МожетБыть("s")
            .Либо("ftp")
            .ВСтроку(),
        ЭкранироватьПереданноеЗначение
    )
    .Затем("://")
    .ЧтоНибудьНоНе(" ")
    .КонецСтроки();
    
ТекстРегулярногоВыражения = ВербальноеВыражение.ВСтроку();
Сообщить(ТекстРегулярногоВыражения); 

Показать



P.S. а вы никогда не задумывались над тем почему вместо изучения регулярок и сдачи их на экзамене просто не поменять формат журнала технологического. Сюрррреализм.
Romazan; Yakud3a; Rustig; olegtymko; +4 Ответить
31. starik-2005 2180 06.05.18 13:57 Сейчас в теме
(30)
P.S. а вы никогда не задумывались над тем почему вместо изучения регулярок и сдачи их на экзамене просто не поменять формат журнала технологического. Сюрррреализм.
А какой формат ТЖ поможет сделать его анализ без поиска текста? Даже интересно стало...
32. Darklight 22 10.04.20 10:41 Сейчас в теме
(31)Возможно, в формате JSON или YAML (как это сейчас достаточно популярно в других системах, формирующих логи - в основном в WEB; да и готовых шин данных и парсеров логов в в таком формате уже создано полно) - когда за парсинг строки будет отвечать уже встроенная библиотека разбора данного формата. Хотя это не отменяет того, что уже в разобранных "сообщениях" не нужно делать поиск по регуляркам в их полях. Ну даже если не по регуляркам - то просто на поиск по ключу(ам) для наложения фильтров отбора и ветвления. Впрочем, такой поиск уже куда проще описать даже с регулярками, чем парсить исходные строки Т/Ж. Но, скорость, разбора тут конечно немного снизится (из за нескольких прогонов одного и того же текста; не знаю насколько существенно - если не рассматривать алгоритм разбора на 1С - на 1С то явно заметно просядет).

Хотя я, вот, не считаю такое проседание производительности существенным недостатком. Ибо - разово можно и подождать. А для регулярной массовой обработки - лучше перейти на применение "специализированных" инструментов обработки больших объёмов текстовых данных - от ElasticSearch до, скажем, Яндекс ClickHouse (да даже MS SQLServer или PostgreSQL тут подойдут - если объёмы исходных данных не измеряются терабайтами в месяц) - куда логи проще загнать целиком - и уже там запросами их анализировать - особенно учитывая что загонять можно в реальном времени или в условно нерабочее время - о того скорость их парсинга не будет существенной. А вот анализировать будет куда удобнее и быстрее запросами (в расширенных диалектах этих СУБД), чем регулярными выражениями

P.S.
Прошу прощения за то, что написал этот ответ спустя 2 года после сообщения - я просветился за это время ;-) Тем более никто так и не ответил ранее :-( а статью эту сейчас подняли из небытия и её снова читают
33. starik-2005 2180 10.04.20 11:45 Сейчас в теме
(32) я про JSON на прошлой неделе (если не на этой) писал, что было бы не плохо, ибо: Elastic, jsonb postgres, ...
С другой стороны, сейчас ТЖ - 'это CSV, а для него есть уже кем-то написанные утилиты, которые преобразуют CSV в JSON.
С третьей стороны, есть мнение, что ТЖ - информация эфемерная, которую не нужно хранить постоянно, ибо завтра код поменялся и производительность просела в другом месте. Хранить это нет никакого смысла после того, как произведен анализ, а уж после найденного решения и подавно. Поэтому нужен формат, который бы максимально просто подвергался исследованию, а тут CSV уже действительно без всех этих парсеров на awk со сложной для обычного админа структурой слабо подходит для исследования.
34. Darklight 22 10.04.20 12:11 Сейчас в теме
(33)Да - самописные инструменты парсинга и преобразования текущего формата Т/Ж есть - я не спорю, просто это всё лишнее время на конвертацию, посему и написал, что не вижу в этом проблем по производительности - на больших объёмах куда важнее наладить эффективный сбор и консолидацию логов (и их эффективное хранение) - чем чахнуть над повышением эффективности парсинга и сложных регулярках. Вот только на экзамене по эксперту пока ещё требуют чтобы испытуемые непременно умели чахнуть над регулярками. Впрочем, изучить их конечно надо. Как и некоторые юниксовые утилиты - перекачевавшие и в windows по разбору текстовых файлов. И это действительно может быть полезно при выездном анализе производительности такими специалистами. Но к реальной стационарной практике анализа Т/Ж это имеет мало общего. Тут применяются совсем иные инструменты. Куда лучше - запихнуть лог в СУБД разными готовыми утилитами (ну или анализировать его налету запросами а-ля SQL при помощи, так же, имеющихся самописных утилит), чем парсить его сложными регулярками (учитывая что формат лога Т/Ж к парсингу регулярками не особо благоволит).

Но всё же, мировая тенденция сейчас - это формирование логово в формате JSON (тенденция не значит правило), и хорошо было бы компании 1С всё-таки добавить поддержку этого формата тоже (пусть в cfg файле бы это настраивалось - CSV или JSON, JSONB, YAML), а если бы ещё можно было бы настроить сразу трансляцию в сервис (WEB, HTTP, в т.ч. c указанием формата преобразования исходного сообщения - ну это я про возможности FileBeat намекаю только со встроенной поддержкой в платформу) или в БД (по заданной настройке подключения и формату запроса на вставку) - то вообще было бы очень круто!
Ну и стыдно должно быть - когда в продукте до сих пор нет встроенного средства хотя бы примитивного разбора а и анализа логов Т/Ж - для как раз выездных случаев разбора специалистами - когда нет возможности поднять более мощную инфраструктуру по их разбору и анализу во внешних программах (в том числе, упомянутых мной выше).

А по поводу хранения - зачастую даже в изменчивой природе конфигураций и, как следствие, данных в логах, имеет смысл хранить логи некоторое время - чтобы иметь возможность делать кросс-анализ (как было и как стало). Да и в крупных компаниях даже за сутки объёмы логово могут быть достаточно велики - чтобы сразу направлять их в условно "колоночную" СУБД, чтобы сократить занимаемое ими место и повысить скорость анализа.
Ну и зачастую, лучше писать в логи информации побольше (подетальнее) - чтобы было что потом анализировать (пусть это и снижает производительность сервера 1С - SSD тут в помощь). Просто делать это можно лишь периодически, хотя можно и постоянно - это уже зависит от того, как грамотно этими логами смогут потом распорядиться специалисты
35. starik-2005 2180 10.04.20 13:57 Сейчас в теме
(34) Про JSON я тут как раз не спорю, а идея передавать это сразу чем-нибудь через HTTP - просто бомба, ибо сэкономила бы кучу времени и средств для доставки данных в целевую систему анализа.

С другой стороны, у 1С есть тот же APDEX, который бы уже давно нужно встроить в платформу, чтобы она сама эту информацию о времени записи документа, открытии формы, проведении и прочем - фактически выбранным событиям - записывала в идеале в очередь или куда там (с настраиваемым интерфейсом). Я даже на С/Питоне/Прочем когда разрабатываю приложения, то периодически озабочиваюсь регистрацией времени для тех или иных вызовов (хотя там, слава богу, с профилированием и утилитами для этого и так проблем нет).

И вот исходя из показателей APDEX следует в идеале запускать механизм мониторинга в автоматическом режиме, дальше уже собирается ТЖ для соответствующих объектов, по которым произошла просадка APDEX, и уже готовый отчет с первичным анализом должен прилететь на хелп-деск или куда там процесс маршрутизирован в организации. Ну и, вообще в идеале, к нему должны цепляться данные о графике регламентных работ, которые производятся в интервал просадки, если они есть. А чтобы были именно они, то все регламенты должны быть "бюрократически" согласованы и акцептованы у всех ключевых стейкхолдеров.
Darklight; +1 Ответить
36. Darklight 22 10.04.20 15:26 Сейчас в теме
(35)Полностью разделяю Ваши взгляды на эту тему
37. check2 125 11.04.20 20:41 Сейчас в теме
Регулярные выражение это отлично, но не в этом сложность ИМХО. Их достаточно легко освоить. Проблема в другом в "№;*;%:№;ом количестве параметров для команд perl, sed, grep, awk. Мало того, эти параметры различаются в bash Linux и MIGW64. Да и синтаксис grep не совсем соответствует спецификации регулярки в Википедии. Например у меня было не понимание - зачем соединять строки в одну чтобы искать то что нужно? Ведь есть модификатор (?s) Оказывается, ни в одном варианте grep или egrep этот модификатор не поддерживается. Ну и в чистом виде поиска и вытаскивания выражений в скобках (some expression) и подстановка их в другой шаблон как в notepad++ нет ни в одной из перечисленных команд выше. Авторы Морозов и другие зачем то предлагают заменять переносы строк через perl, хотя достаточно tr. А и ещё... \w+ для русских идентификаторов не работает. НИКОГДА. Только [А-Яа-я]{1,}. В общем даже зная регулярки по спецификации как в википедии (наиболее полно реализованы в notepad++ и, спасибо разработчикам Эклипса в EDT НО \w+ тоже не пашет в EDT).
И каждый раз набрав регулярное выражение вспоминаю стишок.
Стою на асфальте я в лыжи обутый
То ли лыжи не едут, то ли я ?*%;*№*тый

Есть и ещё один важный момент. Я начал плотно работать с регулярными выражениями не так давно - года 3-4 назад. Вот эти последовательности cat rphost*/*.log | perl -n -e 'if (/^\d\d:\d\d\.\d+/) {$event =~ s/.\n/<line>/g; print $event."\n"; $event = "";} $event .= $_; END{print $event};' | perl -pe 's/\xef\xbb\xbf//g' | grep -P "SDBL.*Func=(Commit|Rollback)Transaction.*Context" | perl -pe 's/^\d+:\d+.\d+-//g' | perl -pe 's/,SDBL,.*Context.*<line>[ \t]+/,Context=/g' | perl -pe 's/,SDBL,.*Context=/,Context=/g' | sed 's/<line>//g' | head - бесполезно заучивать если у вас нет записной книжки под рукой. Моск не дом советов. Мой не запоминает. Проще коран выучить не зная арабского.
Только понимание каждой из команд и ежедневное использование позволят "с лёгкостью" пропарсить ТЖ. Заметил - 3 дня не использовал и уже забыл опции для perl чтобы заменить шило на мыло, вот не помню чтоб поставить между perl и 's/мыло/шило/g'. И начинается: --help а дальше почти перебор. Потому что букв две: -pe.
38. vasilev2015 1847 11.04.20 23:07 Сейчас в теме
(37) Здравствуйте !

у меня в общем, такие же ощущения, поэтому я хочу создать библиотеку скриптов Bash для парсинга ТЖ. И закрыть этот вопрос. Посмотрите пожалуйста другие мои статьи, например https://infostart.ru/public/1217031/. Буду рад любой конструктивной критике.
39. check2 125 12.04.20 14:57 Сейчас в теме
(38) Николай, я не сколько не сомневаюсь что готовые фрагменты анализа ТЖ за$bash'енные в своё время и опубликованные здесь - реально круты :) Но, Саша (М) говорил так. Прихали на секретный завод. Интернета нет. Телефон отобрали на входе. Нет ничего, ТЖ, голые руки - и bash. Вот как хочешь - так и $bash :). Поэтому всё что выше было - это не критика, а лишь призыв к пониманию, что если не будет доступа к копипасту - выручат лишь глубокие знания и понимания команд bash. Статьи посмотрел, они будут полезны при самостоятельном разборе, чтобы в голове отложилось "что вот ещё так можно" но заучивать и копипастить их, увы, будет бесполезно (по крайней мере для меня). У меня был случай (года 2 назад), который описывал Александр М. У меня был телефон, и о чудо даже работал интернет на нём! Я раз 5 перебивал строчки с мобилы на клаве компа. И всё безнадёжно - не вероятно неудобно, я терял строку, ошибался. Только понимание, только хардкор.
Оставьте свое сообщение
Вопросы с вознаграждением