Linux: Does find | xargs grep have limitations?

Question

I've historically performed something like:

find . 2>/dev/null | xargs grep -i something_to_find 2>/dev/null

If my pwd is barfoo (/foo/bar/baz/foofoo/foobar/foobaz/barfoo) it finds matches. However, if I cd to /foo, it no longer finds the matches.

---

Conditions:

• permissions are all 775
• the directories are not symbolic links
• they are all on the same file system / server

---

So I'm curious if there is a default -maxdepth that is applied to find, or are there other constraints as to why this would not work?

---

Additional Info:

Some great comments have been posted. Here is some additional info:

• this is for GNU, not POSIX
• find --version : GNU find version 4.2.27
• grep --version : (GNU grep) 2.5.1
• xargs --version : GNU xargs version 4.2.27
• removing the redirection of STDERR has no bearing on the result, or lack thereof
• the path to the files in barfoo (known to work) do not have spaces, however files in other directories in /foo/bar may have spaces; though, I don't see how that would be problematic
• I realize I wasn't specific on the path, but these are all well-named directories, not to be confused with any devices

Interesting Finding:

The first doesn't work, but the second does:

1. find . -type f | xargs grep -i something_to_find
2. find . -type f -name "*.ext" | xargs grep -i something_to_find

Even odder is that -name "*.*" does not work, the file extension has to be given; which could be problematic when searching for something.

I'm wondering if there is termination after a max error count, or maximum buffer size. I know there are a lot of files in these directories, but the fact it works when specifying the filetype (limiting results) is interesting.

Answer 1

Directories with names that contain spaces, visible from /foo/bar and not from barfoo, are the likely culprits. xargs splits its output by spaces, and also interprets quotes, backslashes, and even the _ character—see the manual for details, so whitespace in file or directory names cause it to pass incomplete file names to grep.

To work around this issue, use find -print0 in conjunction with xargs -0, like this:

find . -print0 2>/dev/null | xargs -0 grep -i something_to_find 2>/dev/null

The -print0 option tells find to separate file names with a binary 0 character, which cannot appear in a valid file name. The corresponding -0 option tells part to use that same character as the separator, and also not to interpret quotes and backslashes.

Answer 2

Given your latest edit I'd like to point you at my comment above again:

Since you mention "same server": Is there any chance that special files like /proc/kcore or /dev/zero are anywhere in the path? That would certainly stop grep from going any further.....

Since adding an extension produces different results from the run w/o that kind of rules spaces as the culprit out.

Answer 3

Try

grep -r something_to_find 2>/dev/null

"grep -r ..." will search all files recursively from $PWD.

Answer 4

Try this:

find . -type f -print0 | tee /tmp/file-list | xargs -0 egrep whatever

Does /tmp/file-list (view it with something that doesn't mind nulls) contain your desired file(s)? If no, it's a find problem. If yes, it's an xargs matter.

I've intentionally not 2>'d away the errors. They may be useful.