krep 2.0.0

используются алгоритмы Бойера—Мура—Хорспула, Кнута—Морриса—Пратта или Ахо—Корасик.

Как много незнакомых слов.

Есть какие-нибудь примеры использования, показывающие, чем конкретно оно лучше grep, rg, ag и т. д.

Щас тебе понаставят. :)

Да пускай ставят. Я не стыжусь незнания. Стыдно, когда не хочешь учиться или узнавать, а не когда не знаешь :)

(Я там во втором абзаце вопросительный знак в конце забыл, не успел поправить, но это вопрос. Чисто в производительности дело, или есть ещё какие-то фичи, скрытые за всем этим?)

Тогда пригодится https://smart-tool.github.io/smart/.
Или нет.

Ну тут возникает вопрос: насколько все эти крутые улучшения релевантны для реального мира. Потому что при замене grep-а на krep вокруг всё равно останутся всё те же текстовые утилиты. И ускорение вдвое в поиске сожрётся медленностью какого-нибудь, условно говоря, sort-а, в том же конвеере обработки данных.

чем конкретно оно лучше grep, rg, ag и т. д.

Я ей особо не пользуюсь, но вот чем хуже: что-то не очень хорошо с не-ASCII-поиском с некоторыми опциями.

Ну тут возникает вопрос: насколько все эти крутые улучшения релевантны для реального мира. Потому что при замене grep-а на krep вокруг всё равно останутся всё те же текстовые утилиты. И ускорение вдвое в поиске сожрётся медленностью какого-нибудь, условно говоря, sort-а, в том же конвеере обработки данных.

Ну вообще есть немало юзкейсов, где остальные утилиты и не нужны, или же сортировка занимает буквально меньше секунды. А поиск до этого — скажем 50 секунд одной утилитой и 15 другой. Даже просто поиск по гигабайтам логов, там просто надо «отгрепать», а сортировать особо ничего и не требуется, оно и так отсортировано, или на вход сортировщику из всех гигабайт идут пара десятков строк, и он отрабатывает моментально.

По зависимостям тянет половину KDE?

Aho-Karasique. Используется алгоритм с развертыванием конечного автомата из пакетов и карпов (в пакете) для словаря. Все понятно же.

И ускорение вдвое в поиске сожрётся медленностью какого-нибудь, условно говоря, sort-а

там Бернштейн как раз на днях выпустил новую версию своего djbsort))

поиск по гигабайтам логов, там просто надо

сдаётся мне что современные логи (потенциально) таких объёмов сразу загоняются в базы и уже там происходят ротация/сжатие/поиск/фильтры

то есть из ком.строки: `krep «жезеляко» 100Gb.log` это заявка на увольнение кого-то там, возможно админа

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

Ну и с логами это просто самый простой пример — это те самые данные, которых может быть много, и которые при этом редко требуют много утилит в конвеере, просто поиск.

Загонять какой-нибудь access.log nginx’овский, по которому раз в год может быть нужно что-то загрепать, в БД — скорее это может быть заявкой на увольнение за оверинжениринг.

Что только не придумают, лишь бы Loki/Logstash/Greylog не использовать.

то есть из ком.строки: krep «жезеляко» 100Gb.log это заявка на увольнение кого-то там, возможно админа

Так в общем и есть.

Загонять какой-нибудь access.log nginx’овский, по которому раз в год может быть нужно что-то загрепать, в БД — скорее это может быть заявкой на увольнение за оверинжениринг.

Оверинжинириг - писать грепалку с SIMD-оптимизациями, а пихать логи в центральное хранилище принято со времен syslog’а, который старше большинства местных комментаторов.

Основной особенностью должно быть включение в состав KDE.

высокопроизводительной многопоточной ... оптимизированной ... утилиты

Звучит как что-то стрёмное на JS или на каких-нибудь zig или go... Но нет, хороший софт на C.

Ну хоть qmail больше не форсит...

день добрый!
прочитал и, да, не хватило «чуть более» развернутого описания.
использую для локального/контекстного поиска recoll (очень старую версию, переделанную под себя), результаты выдает мгновенно (как и ожидается). хотелось бы понять плюс/минус, как оно соотноситься (без обращения на gui/console).

спасибо

Нейминг криповый ). Я бы назвал rrg (ripripgrep)

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

судя по описанию, оно использует не регексы, а самые базовые алгоритмы поиска строки в тексте. Это сильно упрощает реализацию, устраняя пространство для возможных багов, уязвимостей и зависимостей, ну и ускоряет тоже, благодаря отказу от регексов.

Я вот не помню, грепал ли когда-нибудь вообще регексы. И на самом деле хотел написать подобную штуку, но похоже все написано до нас.

Почему нет поддержки GPU и MPI? Кто в здравом уме будет использовать утилиту для поиска строк, которая не масштабируется на 4096 узлов?

для реального мира.

Такой нейминг позволяет использовать grep в Gnome и krep а KDE.

Зачем оно целый ман вывело при ошибке? За что не люблю новомодный хипстерский софт, так это за то, что он ведет себя по-вендовому.

И xrep в XFCE...

Я вот не помню, грепал ли когда-нибудь вообще регексы

То есть ты грепал не регэкспы, но про ключ -F не слышал? Я вот grep без него не использую за редкими исключениями.

Да, ещё гит так же делает, осуждаем.

В 2026 уже пора научиться делать подобные утилиты в качестве либы (library first), а к ней уже cli/tui/gui frontend и API для разных языков.

Во FreeBSD уже.

Я тоже могу сказать, чем хуже.

Ее нет в основных репах, в отличие от того же ripgrep. На этом же измерения можно и закончить.

Алгоритм Бойера-Мура поиска подстроки в строке - классика программирования.

полюбопытствовал как именно сделана «SIMD-оптимизация с поддержкой SSE4.2, AVX2 и NEON.» и теперь буду ругаться :

1. код кроме автора опуса разбирать никто не будет. То есть проект мёртво-рожден. Функции по 900 строк это сильно

2. оптимизация выполнена на уровне #include <immintrin.h>, похоже что откуда-то списанного. Вроде бы и всё, может ещё как-то но см. п.1, код-простыня

3. нахренато впихан «colored output» но с захаркоженными цветами и esc-последовательностями.

Во FreeBSD уже.

Что-то в портах не нахожу.

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

А вообще сейчас я пользуюсь ugrep, потому что там можно написать конфиг и еще и индекс построить. В конфиге у меня есть --fixed-strings, да.

Я имел ввиду

В 2026 уже пора научиться делать подобные утилиты в качестве либы (library first), а к ней уже cli/tui/gui frontend и API для разных языков.

$ ldd /usr/bin/grep 
/usr/bin/grep:
	libregex.so.1 => /usr/lib/libregex.so.1 (0x68ad6fce000)
...

Чем же ответит ripgrep?

Звучит как что-то стрёмное на JS или на каких-нибудь zig или go…

Ставить в один ряд JS, Zig и Go. Звучит, как провокация.

оптимизация выполнена на уровне

Обычные интринсики.

сдаётся мне что современные логи (потенциально) таких объёмов сразу загоняются в базы и уже там происходят ротация/сжатие/поиск/фильтры

1С попытался. Греп по логу блокирует транзакции на запись и подвешивает текущую работу.

Регулярно натыкаюсь на упоминания диких цифр по VM для программ на go. Сам лично был в ужасе от того, как ловко сжирает всю память obfs4.

диких цифр по VM для программ на go

У зига синтаксис объективно лучше, чем у Си (нет улиткового разбора, макросов, эллипсисов).

Был там один минус – что документации мало–, однако вот давеча сказал годной дорогой нейронке сделать мне проект на зиге. Важно, что с его синтаксисом последней ночной сборки. Нейронка буквально пошла в исходники std из инсталляции, недолго там пошуршала, и справилась с заданием.

Если не поддерживает поиск бинарного блоба в форме хексовой строки, то не нужно.

Если не поддерживает поиск бинарного блоба в форме хексовой строки, то не нужно.

krep «cast oom_killer» /dev/random :-)

Aho-Karasique. Используется алгоритм с развертыванием конечного автомата из пакетов и карпов (в пакете) для словаря.

Где-то ещё должны быть караси.

Круто для большой нагрузки, наверное.

А в простых личных целях уже лет так n использую ack, написанный на Perl.

заявкой на увольнение за оверинжениринг.

Было бы неплохо, но в реальности оверинжиниринг чаще наказывается премией чем увольнением.

Если верить штатному system monitor, то grep расправляется с файлами со скоростью около 230 мб/сек. У меня есть ощущение, что это уже предел для ssd. Если так, то к чему или зачем столько внимания на высокопроизводительную многопоточность?

Скорее всего я чего-то не понимаю, а понимать, скажу откровенно, очень хочется.

https://github.com/davidesantangelo/krep/releases/tag/v2.1.0:

• Поддержка чтения шаблона поиска из stdin: echo 'pattern' | krep -f - target.txt.
• Добавлен ключ --gitignore для обработки файлов .gitignore при рекурсивном поиске.
• Добавлена возможность «ручного» выбора алгоритма поиска: --algo auto (по умолчанию), bm (Boyer-Moore-Horspool) или kmp (Knuth-Morris-Pratt). Aho-Corasick выбирается автоматически при поиске по нескольким шаблонам.
• Добавлены tar.gz со сборками Linux x86_64, macOS arm64 и macOS x86_64.

лишь бы Loki/Logstash/Greylog не использовать.

Victoria Logs забыли

Если не поддерживает поиск бинарного блоба в форме хексовой строки, то не нужно.

Обяз при этом с вариантами BE/LE