Оболочки → Регулярные выражения внутри bash
Занялся я как-то оптимизацией скорости работы своего скрипта. Алгоритм был уже вовсю отполирован, распараллелен и выполнялся уже более чем за сносное время. Лишь изредка, облизывая части кода, шебурша места, использующие внешние команды и приводя в благоухающую гармонию встроенными командами оболочки, обращал внимание на застоявшуюся роль труженика — потокового редактора sed, всё так же старательно обрабатывавшего регулярные выражения в моём расцветающем скрипте.
Существует множество мест, где люди грызут друг другу глотки и отстаивают честь своего любимого редактора в грозной войне sed vs awk vs grep vs …
Тем не менее, большинство знает, что замена вызовов внешних команд на внутренние зачастую значительно ускоряет критические места скрипта, заставляет улыбаться автора, тратя меньше его времени на ожидание за чашкой кофе «пока закончится обработка». Это, в некотором смысле, некоторая неадекватность, если он знает язык Си и может значительно ускорить программу переписыванием кода на Сях; но не следует сразу записывать его в сумасшедшие — некоторые скрипты довольно объемны для переноса кода и используют различные команды, заставляя код пухнуть от нахальных вставок системных вызовов exec().
Итак, как бы то ни было, разработчики bash третьей версии наделили нас возможностью пользоваться встроенными регулярными выражениями внутри команды [[ при помощи =~.
Большинство результатов на гугление про такую способность bash выносят один и тот же вердикт — «пользоваться регулярными выражениями внутри bash — моветон».
В данной статье я попытаюсь вынести вердикт, насколько всё плохо (а оно действительно как-то нехорошо).
Существует множество мест, где люди грызут друг другу глотки и отстаивают честь своего любимого редактора в грозной войне sed vs awk vs grep vs …
Тем не менее, большинство знает, что замена вызовов внешних команд на внутренние зачастую значительно ускоряет критические места скрипта, заставляет улыбаться автора, тратя меньше его времени на ожидание за чашкой кофе «пока закончится обработка». Это, в некотором смысле, некоторая неадекватность, если он знает язык Си и может значительно ускорить программу переписыванием кода на Сях; но не следует сразу записывать его в сумасшедшие — некоторые скрипты довольно объемны для переноса кода и используют различные команды, заставляя код пухнуть от нахальных вставок системных вызовов exec().
Итак, как бы то ни было, разработчики bash третьей версии наделили нас возможностью пользоваться встроенными регулярными выражениями внутри команды [[ при помощи =~.
Большинство результатов на гугление про такую способность bash выносят один и тот же вердикт — «пользоваться регулярными выражениями внутри bash — моветон».
В данной статье я попытаюсь вынести вердикт, насколько всё плохо (а оно действительно как-то нехорошо).
JavaScript → Фильтрация текстов по списку регулярных выражений
В сборнике скриптов для сайта HabrAjax 0.79 появилась возможность сворачивания аннотаций в ленте для указанных читателем авторов и по совпадению указанных строк (можно назвать, сворачивающих строк). Например, если читатель хочет выделить произведения некоторого автора, показывая только название статьи в любой ленте (главная, избранное, поиск), он вносит имя автора в специальный список и включает настройку сворачивания. Или — сворачивать аннотации, если в названии или в тексте аннотации встречается некоторая последовательность символов (не слов, а символов). Второй фильтр работает на регулярных выражениях, поэтому читатель фактически задаёт не строки, разделённые запятыми, а тела регулярных выражений, с игнорированием размера букв, но с учётом всех символов и пробелов.
Регулярные выражения → Объемные регулярные выражения
Друзья,
Передо мной стоит задача разобрать несколько тысяч различных печатных форм.
К счастью, различия в них не сильно большие (где-то больше параметров, где-то меньше), где-то добавлен столбец и т.д. В целом, по контексту можно понять, где и что находится. т.е. очень напрашивается для использования механизм регулярных выражений. Но, поскольку это не текст в чистом виде, контекст регулярного выражения необходимо задавать не только в форме «предшествует/следует за», но и в форме направления — «выше», «ниже».
И вот я подумал, может быть стоит внести (а может это уже кто-то сделал?) возможность в механизм регулярых выражений указания направления (контекста), что сделает их еще более мощными и расширит область их применимости.
Можно пойти дальше и, например, найдя на картинке глаз, предположить, что он находится в определенном соотношении с другими частями лица, и написать регулярное выражение для выделения паттернов не только в текстах, но и в изображениях. И в пространствах.
Кто-нибудь сталкивался с чем-нибудь подобным?
Передо мной стоит задача разобрать несколько тысяч различных печатных форм.
К счастью, различия в них не сильно большие (где-то больше параметров, где-то меньше), где-то добавлен столбец и т.д. В целом, по контексту можно понять, где и что находится. т.е. очень напрашивается для использования механизм регулярных выражений. Но, поскольку это не текст в чистом виде, контекст регулярного выражения необходимо задавать не только в форме «предшествует/следует за», но и в форме направления — «выше», «ниже».
И вот я подумал, может быть стоит внести (а может это уже кто-то сделал?) возможность в механизм регулярых выражений указания направления (контекста), что сделает их еще более мощными и расширит область их применимости.
Можно пойти дальше и, например, найдя на картинке глаз, предположить, что он находится в определенном соотношении с другими частями лица, и написать регулярное выражение для выделения паттернов не только в текстах, но и в изображениях. И в пространствах.
Кто-нибудь сталкивался с чем-нибудь подобным?
Веб-разработка → Регулярные выражения для валидации распространенных видов данных
Для проверки текстовых полей на валидность обычно используют регулярные выражения. Существует несколько наиболе распространенных видов таких даных, как например номер кредитки, дата в определенном формате и т. д. На сайте html5pattern.com собирается коллекция регулярных выражений для таких данных (там это позиционируется, как возможное содержимое html5-атрибута pattern у inpit-элементов, но эти регулярные выражения можно использовать и для привычной валидации с помощью javascript). Актуальные для российской аудитории примеры, вместе с соответствующими регулярными выражениями вы можете посмотреть под катом.
VIM → О заменах в Vim, использующих регулярные выражения из песочницы
Привет, хабр! Ни для кого не секрет, что старина Vim очень хорош для решения разнообразнейшего круга проблем. Я бы хотел немного пописать об одной из составляющих, которые делают наш любимый редактор настолько мощным, насколько мощным он является — об инструментарии замен, использующем регулярные выражения. Свое повествование я планирую построить, рассказывая о том, как я решал пару специфических задач, и дополняя этот рассказ некоторыми базовыми справочными сведениями.
Python → PDF-принтер Хабра с подсветкой кода на Python из песочницы
На написание данной программы (а в последствии и статьи) меня сподвиг вот этот пост. Так уж вышло, что я имею привычку по-возможности сохранять прочитанные статьи, поскольку все помнить невозможно, и неизвестно когда что может пригодиться. Так что, прочитав вышеупомянутый пост и вспомнив про столь дорогую мне возможность печатать в PDF страницы из Википедии, закономерно появилась мыслишка сделать такой же «принтер» для Хабра, чтоб иметь возможность заполучить в личный архив вызвавшие у меня интерес статьи.
Первой попыткой было использование столь любезно предоставленной автором поста-вдохновителя программы. И практически сразу нашлись грабли, которые игнорировать было выше моих сил. Грабли эти — подсветка кода.
Сразу оговорюсь, на Хабре я новичок и как что работает имею очень смутное понятие. Однако взглянув на исходник страницы со статьей, в которой представлен фрагмент кода, стал понятен источник проблемы. И он *барабанная дробь* в том, что раскраской кода занимается JavaScript. Нет, для чтения через браузер это конечно хорошо и круто, но питоновская pisa, которая и занимается отрисовкой страницы в PDF, код раскраски выполнить не может в принципе.
Возникла идея — надо что-то придумать.
Первой попыткой было использование столь любезно предоставленной автором поста-вдохновителя программы. И практически сразу нашлись грабли, которые игнорировать было выше моих сил. Грабли эти — подсветка кода.
Сразу оговорюсь, на Хабре я новичок и как что работает имею очень смутное понятие. Однако взглянув на исходник страницы со статьей, в которой представлен фрагмент кода, стал понятен источник проблемы. И он *барабанная дробь* в том, что раскраской кода занимается JavaScript. Нет, для чтения через браузер это конечно хорошо и круто, но питоновская pisa, которая и занимается отрисовкой страницы в PDF, код раскраски выполнить не может в принципе.
Возникла идея — надо что-то придумать.
Регулярные выражения → Префиксная оптимизация регулярных выражений на Java
Я хочу рассказать о простом способе оптимизации регулярных выражений, а точнее словарей. Я видел некоторые проекты, которые оптимизируют конечные автоматы, пакеты которые делают быструю разметку словаря в тексте, но так чтобы просто взять словарь и собрать регулярное выражение, которое можно было бы передать любому движку регулярных выражений — такого пока не видел.
Системное администрирование → Автоматизация работы со статическими маршрутами на сети FreeBSD-серверов из песочницы
С чего всё началось
В провайдере, где я работаю, так исторически сложилось, что клиентские сети затерминированы на FreeBSD-серверах со статической маршрутизацией в соединяющих эти сервера коммутационных полях. Соответственно, при добавлении новой сети маршруты для неё надо прописывать на всех серверах по отдельности. Добавив к этому человеческий фактор, может оказаться, что некоторые сервера при добавлении или изменении маршрута будут забыты и пропущены. В связи с этим логичным становится как-то автоматизировать этот процесс.
Реализация
Исходим из того, что у нас есть некоторое количество серверов под управлением FreeBSD, и при добавлении нового маршрута (например, на одном из этих серверов была затерминирована новая клиентская сеть) он должен быть прописан на всех этих серверах.
Для начала создадим текстовый файл, каждая строчка которого являет собой адрес одного сервера, и для каждого из этих серверов настроим авторизацию по ключу (как это сделать, описано, например, здесь).
Пример файла-списка серверов:
192.168.0.1
192.168.1.1
mainserver.yourdomain.ruДальнейшую работу будет делать связка из двух shell-скриптов:
Python → Регулярные выражения, пособие для новичков. Часть 2
В первой половине этого пособия мы раскрыли лишь малую часть возможностей регулярных выражений. Во второй, большей, половине мы рассмотрим некоторые новые метасимволы, то, как использовать группы для получения частей совпавшего текста, разбивать строки, находить и замещать части текста. В конце немного поговорим о распространенных ошибках.
Регулярные выражения → 280 кроказябл или взрывная мощь регулярных выражений
В общем, наверное, как и другой любой начинающий JavaScript прогрммист (2 года назад), мне хотелось все реализовать своими руками. Так возникло ужасающее очень быстрое регулярное выражение из 280 символов.
Приблизительно полтора года назад, я узнал о библиотеке yass, которая была самым быстрым инструментом для поиска DOM элементов в JavaScript по CSS селекторам (ссылка на тесты).
И тут у меня возник ужасный интерес. Я захотел придумать способ, который будет еще быстрее. В то время я как раз читал книгу «Регулярные выражения Библиотека программиста» второе издание от Дж. Фридла. И вот… Это было лето, я еще был студентом и у меня была масса времени. Работа закипела…
Немного истории
Приблизительно полтора года назад, я узнал о библиотеке yass, которая была самым быстрым инструментом для поиска DOM элементов в JavaScript по CSS селекторам (ссылка на тесты).
И тут у меня возник ужасный интерес. Я захотел придумать способ, который будет еще быстрее. В то время я как раз читал книгу «Регулярные выражения Библиотека программиста» второе издание от Дж. Фридла. И вот… Это было лето, я еще был студентом и у меня была масса времени. Работа закипела…