On 9/13/2014 8:25 AM, Edward Ned Harvey (lopser) wrote:
Can anybody explain this behavior to me?I'm searching for files that contain the string "LockFile" in them. I know of one place where it exists already... But the following command only returns one result, which is not the result I already knew existed. Edwards-MacBook-Pro:mono eharvey$ find . -name '*.cs' -or -name '*.c' -or -name '*.h' -exec grep -l LockFile {} \; ./mono/io-layer/io.h So why did it only return one result? Just to prove I know the file I know, and I haven't made a type-o or anything, I specifically repeat the grep command on that specific file: Edwards-MacBook-Pro:mono eharvey$ grep -l LockFile ./mono/metadata/file-io.c ./mono/metadata/file-io.c And indeed, I've confirmed, that file does contain the "LockFile" string. It's not a type-o. So then I wonder if I messed up the find command, perhaps it's not actually searching all the *.cs and *.c and *.h files? To confirm this, I just want to ensure find is actually executing on that particular file: Edwards-MacBook-Pro:mono eharvey$ find . -name '*.cs' -or -name '*.c' -or -name '*.h' | grep file-io.c ./mono/metadata/file-io.c And I see that it *is* executing on that file. So now I'm stumped. Why didn't the original find command identify file-io.c as one of the search results?
FWIW: this is a perfect use case for xargs instead of exec. You'll save a lot of fork/clone system calls and simplify your find. Brandon pointed out the main problem, but consider this alternative:
find . -name '*.cs' -print -o -name '*.c' -print -o -name '*.h' -print | xargs grep file-io.c
_______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
