Bash – Two find commands comparison

bashfindshell

Recently I received this find one-liner, but I'm not able to explain where the difference of the below two comes from:

Example 1

[root@centos share]# find . -exec grep -i "madis" {} /dev/null \;

./names:Madison Randy:300:Product Development

Example 2

[root@centos share]# find . -exec grep -i "madis" {} \;

Madison Randy:300:Product Development

As you can see, in the first one there is the specific file this string derives from and so far I'm really not able to find out why this is happening.

Best Answer

You are telling grep to search 2 locations. grep only shows the full location if multiple locations are searched.

For example

touch /tmp/herp /tmp/derp
cd /tmp
echo "foo" > herp
echo "foo" > derp

Notice how if I search just 1 file, grep omits the file name

grep -i "foo" /tmp/herp
foo

But if I specify multiple search locations, grep says where it found each match

grep -i "foo" herp derp
/tmp/derp:foo
/tmp/herp:foo

Adding the /dev/null is it tricking grep into printing out the full path, by providing 2 arguments.

Related Solutions

Bash Find Command – How to Use Two Bash Commands in -exec

As for the find command, you can also just add more -exec commands in a row:

find . -name "*" -exec chgrp -v new_group '{}' \; -exec chmod -v 770 '{}' \;

Note that this command is, in its result, equivalent of using

chgrp -v new_group file && chmod -v 770 file

on each file.

All the find's parameters such as -name, -exec, -size and so on, are actually tests: find will continue to run them one by one as long as the entire chain so far has evaluated to true. So each consecutive -exec command is executed only if the previous ones returned true (i.e. 0 exit status of the commands). But find also understands logic operators such as or (-o) and not (!). Therefore, to use a chain of -exec tests regardless of the previous results, one would need to use something like this:

find . -name "*" \( -exec chgrp -v new_group {} \; -o -true \) -exec chmod -v 770 {} \;

Number of Backslashes Needed for Escaping Regex Backslash on Command-Line

For the unquoted example, each \\ pair passes one backslash to grep, so 4 backslashes pass two to grep, which translates to a single backslash. 6 backslashes pass three to grep, translating to one backslash and one \c, which is equal to c. One additional backslash does not change anything, because it is translated \c -> c by the shell. Eight backslashes in the shell are four in grep, translated to two, so this does not match anymore.

For the example in double quotes, note what follows your second quote from the bash manpage:

The backslash retains its special meaning only when followed by one of the following characters: $, `, ", \, or newline.

I.e. when you give an odd number of backslashes, the sequence ends in \c, which would be equal to c in the unquoted case, but when quoted, the backslash looses its special meaning, so \c is passed to grep. That is why the range of "possible" backslashes (i.e. those that make up a pattern matching your example file) slides down by one.