Вместо того, чтобы бороться с ack, вы можете просто использовать обычный старый grep, начиная с 1973. Поскольку он использует явно занесенные в черный список файлы, вместо типов файлов из белого списка, он никогда не пропускает правильные результаты.Учитывая пару строк конфигурации (которые я создал в репозитории dotfiles своего домашнего каталога еще в 1990-х годах), grep фактически соответствует или превосходит многие из заявленных преимуществ ack - в частности, скорость: при поиске того же набора файлов grepбыстрее, чем ack.
Конфигурация grep, которая меня радует, выглядит так: в моем .bashrc:
# Custom 'grep' behaviour
# Search recursively
# Ignore binary files
# Output in pretty colors
# Exclude a bunch of files and directories by name
# (this both prevents false positives, and speeds it up)
function grp {
grep -rI --color --exclude-dir=node_modules --exclude-dir=\.bzr --exclude-dir=\.git --exclude-dir=\.hg --exclude-dir=\.svn --exclude-dir=build --exclude-dir=dist --exclude-dir=.tox --exclude=tags "$@"
}
function grpy {
grp --include=*.py "$@"
}
Точный список файлов и каталогов, которые нужно игнорировать, вероятно, будет отличаться для васЯ в основном разработчик Python, и эти настройки работают для меня.
Также легко добавить под-настройки, как я показываю для моего 'grpy', который я использую для grep Python-источника.
Определение таких функций bash предпочтительнее, чем настройка GREP_OPTIONS, которая приведет к тому, что ВСЕ исполнения grep из вашей оболочки входа будут вести себя по-разному, включая те, которые вызываются запущенными вами программами.Эти программы, вероятно, будут отрицать неожиданно отличающееся поведение grep.
Мои новые функции 'grp' и 'grpy' сознательно не скрывают 'grep', так что я все равно могу использовать исходное поведениераз мне это нужно.