ack 错过结果(与 grep 相比)
我确信我误解了 ack 的文件/目录忽略默认值,但也许有人可以为我阐明这一点:
mbuck$ grep logout -R app/views/
Binary file app/views/shared/._header.html.erb.bak.swp matches
Binary file app/views/shared/._header.html.erb.swp matches
app/views/shared/_header.html.erb.bak: <%= link_to logout_text, logout_path, { :title => logout_text, :class => 'login-menuitem' } %>
mbuck$ ack logout app/views/
mbuck$
而...
mbuck$ ack -u logout app/views/
Binary file app/views/shared/._header.html.erb.bak.swp matches
Binary file app/views/shared/._header.html.erb.swp matches
app/views/shared/_header.html.erb.bak
98:<%= link_to logout_text, logout_path, { :title => logout_text, :class => 'login-menuitem' } %>
简单地调用不带选项的 ack
无法找到结果在 .bak
文件中,但使用 --unrestricted
选项调用可以找到结果。但据我所知,ack 默认情况下不会忽略 .bak
文件。
更新
感谢下面有用的评论,以下是我的~/.ackrc
的新内容:
--type-add=ruby=.haml,.rake --type-add=css=.less
I'm sure I'm misunderstanding something about ack's file/directory ignore defaults, but perhaps somebody could shed some light on this for me:
mbuck$ grep logout -R app/views/
Binary file app/views/shared/._header.html.erb.bak.swp matches
Binary file app/views/shared/._header.html.erb.swp matches
app/views/shared/_header.html.erb.bak: <%= link_to logout_text, logout_path, { :title => logout_text, :class => 'login-menuitem' } %>
mbuck$ ack logout app/views/
mbuck$
Whereas...
mbuck$ ack -u logout app/views/
Binary file app/views/shared/._header.html.erb.bak.swp matches
Binary file app/views/shared/._header.html.erb.swp matches
app/views/shared/_header.html.erb.bak
98:<%= link_to logout_text, logout_path, { :title => logout_text, :class => 'login-menuitem' } %>
Simply calling ack
without options can't find the result within a .bak
file, but calling with the --unrestricted
option can find the result. As far as I can tell, though, ack does not ignore .bak
files by default.
UPDATE
Thanks to the helpful comments below, here are the new contents of my ~/.ackrc
:
--type-add=ruby=.haml,.rake --type-add=css=.less
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
ack
的独特之处在于,它没有要忽略的文件类型黑名单,而是有一个要搜索的文件类型白名单。引用该男子的话页:
(请注意,由于命名冲突,我使用的是 Ubuntu,其中二进制文件名为 ack-grep)
ack --help-types 将显示您的 ack 类型列表安装支持。
ack
is peculiar in that it doesn't have a blacklist of file types to ignore, but rather a whitelist of file types that it will search in.To quote from the man page:
(Note that I'm using Ubuntu where the binary is called
ack-grep
due to a naming conflict)ack --help-types
will show a list of types your ack installation supports.如果您对 ack 将搜索哪些文件感到困惑,只需添加 -f 选项即可。它将列出所有发现可搜索的文件。
If you are ever confused about what files ack will be searching, simply add the -f option. It will list all the files that it finds to be searchable.
ack --man 指出:
和
编辑:此外,如果您查看源代码,
bak
文件将被忽略。ack --man
states:and
EDIT: Also if you look at the source code,
bak
files are ignored.您可以使用 1973 年的普通旧 grep,而不是与 ack 搏斗。因为它使用明确列入黑名单的文件,而不是白名单文件类型,所以它永远不会忽略正确的结果。给定几行配置(我在 20 世纪 90 年代在我的主目录“dotfiles”存储库中创建的),grep 实际上匹配或超越了 ack 声称的许多优点 - 特别是速度:当搜索同一组文件时,grep比 ack 更快。
让我高兴的 grep 配置在我的 .bashrc 中看起来像这样:
要忽略的文件和目录的确切列表可能会有所不同:我主要是一名 Python 开发人员,这些设置对我有用。
添加子自定义也很容易,正如我在“grpy”中展示的那样,我用它来 grep Python 源代码。
像这样定义 bash 函数比设置 GREP_OPTIONS 更好,这将导致登录 shell 中所有 grep 的执行行为不同,包括那些由您运行的程序调用的行为。这些程序可能会因 grep 出乎意料的不同行为而呕吐。
我的新函数“grp”和“grpy”故意不隐藏“grep”,这样我仍然可以在需要时随时使用原始行为。
Instead of wrestling with ack, you could just use plain old grep, from 1973. Because it uses explicitly blacklisted files, instead of whitelisted filetypes, it never omits correct results, ever. Given a couple of lines of config (which I created in my home directory 'dotfiles' repo back in the 1990s), grep actually matches or surpasses many of ack's claimed advantages - in particular, speed: When searching the same set of files, grep is faster than ack.
The grep config that makes me happy looks like this, in my .bashrc:
The exact list of files and directories to ignore will probably differ for you: I'm mostly a Python dev and these settings work for me.
It's also easy to add sub-customisations, as I show for my 'grpy', that I use to grep Python source.
Defining bash functions like this is preferable to setting GREP_OPTIONS, which will cause ALL executions of grep from your login shell to behave differently, including those invoked by programs you have run. Those programs will probably barf on the unexpectedly different behaviour of grep.
My new functions, 'grp' and 'grpy', deliberately don't shadow 'grep', so that I can still use the original behaviour any time I need that.