Что: e62e0122a97712662686692c614880e937691464
Когда: 2020-05-19 16:17:05+03:00
Темы: git perl tip
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 (ради скорости), а в остальном это всё без
зависимостей и сторонних утилит.
Сгенерирован: SGBlog 0.34.0