Занялся я как-то оптимизацией скорости работы своего скрипта. Алгоритм был уже вовсю отполирован, распараллелен и выполнялся уже более чем за сносное время. Лишь изредка, облизывая части кода, шебурша места, использующие внешние команды и приводя в благоухающую гармонию встроенными командами оболочки, обращал внимание на застоявшуюся роль труженика — потокового редактора sed, всё так же старательно обрабатывавшего регулярные выражения в моём расцветающем скрипте.
Существует множество мест, где люди грызут друг другу глотки и отстаивают честь своего любимого редактора в грозной войне sed vs awk vs grep vs …
Тем не менее, большинство знает, что замена вызовов внешних команд на внутренние зачастую значительно ускоряет критические места скрипта, заставляет улыбаться автора, тратя меньше его времени на ожидание за чашкой кофе «пока закончится обработка». Это, в некотором смысле, некоторая неадекватность, если он знает язык Си и может значительно ускорить программу переписыванием кода на Сях; но не следует сразу записывать его в сумасшедшие — некоторые скрипты довольно объемны для переноса кода и используют различные команды, заставляя код пухнуть от нахальных вставок системных вызовов exec().
    Итак, как бы то ни было, разработчики bash третьей версии наделили нас возможностью пользоваться встроенными регулярными выражениями внутри команды [[ при помощи =~.
Большинство результатов на гугление про такую способность bash выносят один и тот же вердикт — «пользоваться регулярными выражениями внутри bash — моветон».
В данной статье я попытаюсь вынести вердикт, насколько всё плохо (а оно действительно как-то нехорошо).

Ниже пойдёт речь о методе поиска по выпадающему списку (select).

Для этого требуется поле ввода текста и собственно сам выпадающий список:

<input class="type-search" type="text" />
<select size="10" id="list">
    <option value="val">Text</option>
    ...
    <option value="val*n">Text</option>
</select>

Чтобы результат поиска был нагляднее для пользователя, стоит задать тегу select атрибут size со значением 10.

Добавим к этому немного css:

input, select {
    width: 300px;
    margin: 10px auto;
    display: block;
}

При вводе данных в поле input всё, что не совпадает со строкой поиска, будем скрывать, оставляя в списке только нужные результаты.

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

Немного истории

Приблизительно полтора года назад, я узнал о библиотеке yass, которая была самым быстрым инструментом для поиска DOM элементов в JavaScript по CSS селекторам (ссылка на тесты).
И тут у меня возник ужасный интерес. Я захотел придумать способ, который будет еще быстрее. В то время я как раз читал книгу «Регулярные выражения Библиотека программиста» второе издание от Дж. Фридла. И вот… Это было лето, я еще был студентом и у меня была масса времени. Работа закипела…

На видео показан угон сессии вконтакте.ру, который почему-то до сих пор не использует авторизацию с https и передает пароли открытым текстом.
Дамп трафика собирается программой kismac в формате libpcap и параллельно парсится grep-ом с использованием регулярных выражений, что позволяет в реальном времени выводить на экран все интересующие куки и пароли. При этом не используется никаких анализаторов пакетов.

regexp для перехвата вконтакте.ру:

tail -F pcap.файл | cat | grep -aEo «remixsid=[0-9a-f]+|l=[0-9]{3,12}|p=[0-9a-f]{36}|email=[^&]+&pass=[^ ]+»

для фейсбука:

c_user=[0-9]+|sid=[0-9]{1,5}|xs=[0-9a-f]{32}

Аналогичная конструкция будет работать и с дампом собранным с помощью airdump-ng.

Всем привет! Хочу поделиться решением одной проблемы, связанной с авто-заменой по регулярному выражению в NetBeans.

Описание проблемы

При реализации многих проектов программисту приходится решать проблему локализации, а в частности реализации многоязычной поддержки пользовательского интерфейса. Я часто сталкивался с этой задачей и раньше использовал для этого список(массив) лексем, которые в нужном месте вызывались по ключу (здесь и далее речь пойдет о проектах на PHP, но статья поможет любым разработчикам, которые используют IDE NetBeans):

..it is true that asking regexes to parse arbitrary HTML is like asking Paris Hilton to write an operating system..

Последние версии языка Nemerle включают в состав библиотеку для разбора языков, грамматика которых принадлежит классу PEG.

Что такое PEG?

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

Класс языков, которые можно разобрать с помощью парсеров описанных подобным образом, достаточно широк, чтобы покрыть популярные языки программирования (например, C#) и языки разметки. Очевидно, что он покрывает всю функциональность регулярных выражений.