0. vasilev2015 1830 30.04.18 12:56 Сейчас в теме

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

Шпаргалка к экзамену "Эксперт по технологическим вопросам".

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

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

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

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

Иногда, особенно когда не знаешь почему все работает медленно, надо собрать всё, убрать главные проблемы, и после этого уже работать с ограниченным ТЖ.
Ваш инструмент, я пользовался в том числе и им, в нем действительно удобно сводить данные, но для первичного анализа - regex, ибо в ИР к сожалению уже на 200+ тыс записях (точное число не скажу) вылетает, а клеить анализ за каждые 5 минут - не вариант.
Очень простой пример. На прошлой неделе разбирал один ТЖ, там, помимо тех проблем о которых я догадывался, за час из сервера приложений было больше полумиллиона вызовов НайтиПоКоду в цикле в регламентном задании. С фильтром на длительность эту проблему обнаружить не удастся. НайтиПоКоду вынесен за цикл, стало сразу лучше.
6. tormozit 5824 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 5824 02.05.18 13:07 Сейчас в теме
(8)
Статистика

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

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

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

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

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

АнализТехножурнала = Обработки.ирАнализТехножурнала.Создать();
29. tormozit 5824 04.05.18 20:10 Сейчас в теме
(26) Было бы классно увидеть багрепорт там, где все ожидают его увидеть и подробно оформленный. Проблему воспроизвел.
11. palsergeich 02.05.18 13:48 Сейчас в теме
7. tormozit 5824 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 2177 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 1830 03.05.18 12:46 Сейчас в теме
(15) Про регулярные выражения лучше прочитать в книге Джеффри Фридла «Регулярные выражения». В статье - приложение на практике, приближенное к экзамену.
18. starik-2005 2177 03.05.18 12:52 Сейчас в теме
(17)
Про регулярные выражения лучше прочитать в книге
Вы читали в книге? Как оно там? Сколько страничек? Если читали, то зачем пишите "[0-9]" вместо "\d"?

На мой взгляд, сначала лучше в ВИКИ читнуть, поиграться с notepad++, потом с grep (кстати, никогда не юзал egrep - чем он отличается?), потом с sed. В итоге за пару дней освоится основной функционал, которого уже будет для большинства задач за глаза. А дальше, если хочется стать экспертом не только в 1С, а еще и в регулярных выражениях, можно перейти к книгам (но я бы, лично, из книг порекомендовал "Бытие и Время", а то все хотят стать экспертами, а зачем - не знают )))
19. vasilev2015 1830 03.05.18 12:59 Сейчас в теме
(18) да, читал. Использую [0-9] вместо "\d" поскольку [0-9] работает там, где иногда не работает "\d". Egrep равносилен grep с ключом -e. Экспертом хочу стать по-приколу: могу себе позволить.
20. starik-2005 2177 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 170 03.05.18 21:47 Сейчас в теме
(16) Нормальное название статьи. Тем кто готовится к экзамену на эксперта сразу понятно о чем речь. Автору спасибо.
23. starik-2005 2177 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 1830 04.05.18 08:56 Сейчас в теме
(24) спасибо, полезная информация.
27. Dach 295 04.05.18 10:22 Сейчас в теме
Пользуясь случаем (простите за оффтоп еще раз), раз в ветке отметились мастера разбора ТЖ, хочу посоветоваться...

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

И еще момент... Мы встроили в конфу БСП и подсистему "Оценка производительности". Планируем выявить самые "нехорошие места" сначала ей, а потом, как мне кажется - можно уже и ТЖ более детально настроить... Может кто-то пользовался подсистемой? Поделитесь впечатлениями, плз.
28. vasilev2015 1830 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 2177 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 2177 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 2177 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 124 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 1830 11.04.20 23:07 Сейчас в теме
(37) Здравствуйте !

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

Вакансии

Программист 1С
Екатеринбург
зарплата от 80 000 руб. до 130 000 руб.
Полный день

Автор новостных обзоров на тему 1С и бухучета
Санкт-Петербург
По совместительству

Разработчик 1С
Санкт-Петербург
зарплата от 140 000 руб.
Полный день

Консультант-аналитик 1С
Санкт-Петербург
зарплата от 90 000 руб.
Полный день

Программист 1С
Москва
зарплата от 150 000 руб. до 200 000 руб.
Полный день