ack утилита

https://habr.com/ru/post/502734/
Когда-то тоже использовал ack, даже ставил Vimack (вроде так назывался)
плагин для Vim чтобы он ack использовал для поиска. На тот момент
единственная причина почему использовал: скорость. Буквально на порядок
оно могло быстрее работать GNU grep (не говоря уже про BSD grep).
Однако, с какой-то определённой версии GNU grep очень круто
прооптимизировал свои алгоритмы поиска и стал даже быстрее ack-а
работать. На тот момент (сейчас не смотрел) ack был по сути обёрткой над
Perl-ом. Тогда ещё был ag, который компилировался и был ещё быстрее, но
имел проблемы с Unicode.

Однако, привычки от ack-а у меня остались по удобству работы. Сразу
скажу что BSD grep использовать яростно не рекомендую: наверное он
проще, suckless, компактнее, но он тупо в разы или порядки медленнее
(как и BSD sed). Быстрый вызов быстрого GNU grep-а я сделал вот так:

    GREP=/usr/local/bin/grep
    GREP_ARGS="--color=always --with-filename --line-number --recursive"
    LESS_COLORED="less --RAW-CONTROL-CHARS"
    g() {
        $GREP ${=GREP_ARGS} $@ | ${=LESS_COLORED}
    }
    GS() {
        $GREP ${=GREP_ARGS} $@ | sort --numeric-sort | ${=LESS_COLORED}
    }
    alias -g G="| $GREP --color"

всегда цветной, всегда рекурсивный, показывающий имена файлов и строки
(чтобы это сразу можно было vim-ом открыть, если поиск шёл вне него) и
всегда показывающий это в less-е. "GS" появился относительно недавно и
добавляет числовую сортировку имён файлов. Находясь где угодно я могу
сделать "g whatever" и будет ack-like поведение по умолчанию.

Опции про границы слов (-w) и счётчика (-c) имеются и в GNU grep
современном. Также как и -A/-B. Так что это к ack не относится.

Вся тема по типам файлов... по моему полубредова. Хочется искать только
по JS-ам? В моём случае, это "g whatever **.json". Понимаю, в Bash не
выйдет всего этого, но и не надо перекладывать эту задачу и вести БД
типов файлов на grep/ack/ag/whatever утилиты (ух совсем не Unix-way!).
Больше профита будет от установки zsh-а на сервере!

А остальные плюсы ack-а связаны с Perl-овым поиском. Соглашусь это жутко
и невероятно бесит, что приходится помнить отличия в регулярках в
grep/sed и perl/python и Vim-ом ещё в довесок. В GNU grep вроде есть
какая-то поддержка PCRE, но не уверен что этим можно осилить range
поиск. Да, это могло бы быть плюсом, но... я вот совсем не припомню
когда бы мне нужен был такого уровня поиск по кучи файлам. Ради крайне
редкого случая держать постоянно на готове ack я точно не стал бы, тем
более, привыкнув к нему, париться с установкой на рабочие машины. И ради
этого крайнего случая я просто на месте напишу что-нибудь прямо с самим
perl-ом.

Для git-а, опять же, мало что сравнится по скорости с git grep-ом
родным. И есть колоссальная разница между "приходится, пускай даже
чуть-чуть, ждать" и "не ждать совсем" (десятки миллисекунд, сотня).

А вот поведение vimack плагина для Vim мне нравилось: :Ack whatever и у
меня открывается quickfix окно с результатами поиска. И для эмуляции его
поведения для Vim-а написал тривиальную функу:

    function! s:Vim(pattern)
        let ignorecase_bak=&ignorecase
        set noignorecase
        execute "vimgrep /" . a:pattern . "/ **/*"
        copen
        let &ignorecase=ignorecase_bak
        let g:pylint_disable=1
    endfunction

    command! -nargs=* -complete=file Vim call s:Vim(<q-args>)

которая использует встроенный функционал Vim-а, который медленный, но
это достаточно редко чтобы можно было потерпеть. А при работе в
Git-репозиториях, нужно использовать git grep. Так как в Vim я всегда
ставлю Fugitive плагин, то :Ggrep для вызова git-grep из Vim всегда
имеется. Но от него я тоже хочу получить поведение :Ack:

    function! s:Vmg(pattern)
        silent execute 'Ggrep "' . a:pattern . '"'
        copen
        redraw!
        let g:pylint_disable=1
    endfunction

    command! -nargs=* -complete=file Vmg call s:Vmg(<q-args>)

И всё это я сверхчасто использую. Для FreeBSD в любом случае придётся
поставить GNU grep (ради скорости), а в остальном это всё без
зависимостей и сторонних утилит.