A recursive grep from root directory doesnt work as expected

[yaron1]

Hi,

I do a recursive grep (piped from a find) on the entire file system (from / downward). I do:
find / -type f 2>>1err.txt -print |xargs grep mystring 2>>2err.txt

It simply doesnt find the expected string. While I know at least some files (with permission to read) where the string exists (under a certain directory). When I do:

find /certain_directory/ -type f 2>>1err.txt -print |xargs grep mystring 2>>2err.txt

It will find the string in the expected file in a sub directory of certain_directory.

The 2>> is to avoid the messages on files that my user doesnt have permission to read.

What can be the reason? If its a symbolic link permission problem how can I display or detect it?

It’s a POSIX shell if I’m not wrong.

Thanks for the answers.

[Victor Fridyev]

Hi
I'm afraid, the problem is in xargs format.
Try the following:

find / -type f -exec grep -l mystring {} \;

This works, tested and confirmed.

HTH

[yaron1]

Victor,

Using -exec instead of xargs will create a child process for each output string from the find command to the grep. This is very disadvantageous resources wise.

Thanks.

[James R. Ferguson · Accepted solution]

Hi:

> Using -exec instead of xargs will create a child process for each output string from the find command to the grep. This is very disadvantageous resources wise.

That's true _if_ you terminate the '-exec' argument with a semicolon. If you use a '+' as a terminator, multiple arguments are bundled together and passed en mass to the process spawned --- the equivalent of 'xargs'. Thus:

# find / -type f -exec grep -l mystring {} +

...is very efficient from the standpoint of the spawning of processes.

Regards!

...JRF...

[Dennis Handly]

>It simply doesn't find the expected string.

It should but it may take forever.

>If it's a symbolic link permission problem how can I display or detect it?

Symlink permissions are ignored.
find(1) won't follow symlinks unless you use -follow. But if you are starting in /, that shouldn't matter.

>Victor: the problem is in xargs format.

What's wrong with it? yaron1 had it working with a different find(1).

[Peter Nikitka]

Hi yaron1,

I would check the collected output in the files ?err.txt.
- Does one of the parent directories contain names including spaces? The grep will not get them correctly!
- Maybe the 'find /' lasts forever or you did specify other find-options (-xdev?) which skip /certain_directory ?

mfG Peter

[Steven Schweda]

> - Does one of the parent directories
> contain names including spaces? The grep
> will not get them correctly!

Which "grep"? Why?

rux # uname -a
HP-UX rux B.11.31 U ia64 1678555272 unlimited-user license

rux # ls -l
total 0

rux # pwd
/root/itrc/ro ot

rux # mkdir 'a b'

rux # echo fred > 'a b/c d'

rux # find . -type f -exec grep fred {} \; -exec ls -l {} \;
fred
-rw-r--r-- 1 root sys 5 Nov 16 07:54 ./a b/c d

Some things actually _do_ work, even with
messy file names. Perhaps "find" is smarter
than you think.

[Peter Nikitka]

Hi (Steven),

yaron1 used find ... | xargs

Do you try this?

mfG Peter

[Steven Schweda]

> yaron1 used find ... | xargs

Yes, and someone else didn't, and you didn't
say what you were talking about (other than
"The grep [...]").

> Do you try this?

Why would I? "find -exec" normally does what
I need to do, without adding the
complications of xargs.