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 для разных языков.