Ack skips results (versus grep)

Question

I'm sure I don't understand something about the ack file / directory to ignore the defaults, but maybe someone can 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$ 

While...

 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' } %> 

Just calling ack without parameters cannot find the result in the --unrestricted file, but calling with the --unrestricted parameter can find the result. However, as far as I can tell, ack does not ignore .bak files by default.

UPDATE

Thanks to the helpful comments below, here is the new contents of my ~/.ackrc :

 --type-add = ruby ​​= .haml, .rake
 --type-add = css = .less

Answer 1

ack is different in that it does not have a blacklist of ignored file types, but rather a white list of file types in which it will look.

To quote from the man page:

Without selecting a file, ack-grep searches for files of only those types that it recognizes. If you have a file called foo.wango and ack-grep does not know what a .wango file is, ack-grep will not look for it.

(Note that I'm using Ubuntu, where the binary is called ack-grep due to a name conflict)

ack --help-types displays a list of types supported by the ack installation.

Answer 2

If you are ever confused about which files will be searched, just add the -f option. It will display all the files that, in its opinion, will be searchable.

Answer 3

ack --man :

If you want ack to look for every file, even those that it always ignores coredumps and backup files, use the "-u" switch.

and

Why does ack ignore unknown files by default? ack is designed by a programmer, for programmers, to search for large code trees. Most codebases contain a lot of files in them which source files arent (for example, compiled object files, source control metadata, etc.), and grep has a lot of waste of time looking through all these and also returning matches from these files.

That is why the behavior of searching for things that it does not recognize is one of the strongest points: the speed that you get from searching only the things you want to look at.

EDIT: Also, if you look at the source code, bak files are ignored.

Answer 4

Instead of fighting ack, you can use plain old grep since 1973. Since it uses explicitly blacklisted files and not white file types, it never misses the correct results. Given a couple of configuration lines (which I created in my dotfiles repo home directory back in the 1990s), grep actually matches or exceeds many of the stated benefits - in particular speed: when looking for the same set of grep files faster than ack.

The grep configuration that makes me happy looks like this: in my .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 "$@" } 

The exact list of files and directories to ignore will probably be different for you: I'm basically a Python developer, and these settings work for me.

It is also easy to add subtasks, as I show for my "grpy", which I use for the grep source of Python.

Defining bash functions like this is preferable to setting GREP_OPTIONS, which will cause ALL grep commands from your login shell to behave differently, including those caused by the programs you started. These programs are likely to depend on unexpectedly different grep behavior.

My new features, “grp” and “grpy”, are intentionally not a shadow of “grep”, so I can still use the original behavior anytime I need.