Why does the grep command ignore the period in the search string?

Question

The command that I am using:

find . -type f -name "*.sql" -exec grep -i -l 'schema_name.' {} +

What I want to search is all the files which contain schema_name.. But the find command is ignoring the last . and is only looking for schema_name instead of schema_name.

Solution 1

That's grep issue, not find.

grep matches pattern using regular expression by default, the pattern schema_name. means any character follows the string schema_name.

If you want to match the dot . literally, you have to escape it with a backslash \:

find . -type f -name "*.sql" -exec grep -il 'schema_name\.' {} +

or using -F option:

find . -type f -name "*.sql" -exec grep -Fil 'schema_name.' {} +

Solution 2

You could use fgrep

find . -type f -name "*.sql" -exec fgrep -i -l 'schema_name.' {} +

which on older Unix operating systems may very well be a lot faster (fgrep, grep and egrep used to be 3 different executables, and there fgrep was a lot faster because it omitted everything related to regex entirely - on eg GNU based systems these three programs are just links to the same executable).

Solution 3

Escape the dot in the grep search pattern:

find . -type f -name "*.sql" -exec grep -i -l 'schema_name\.' {} +

Solution 4

Why does the grep command ignore the period in the search string?

It doesn't.

To prove, run

grep . file

which is an easy way to remove all empty lines from file.

In other words, . is the regex atom for any single character (except newline). To literally match a dot, the atom must be escaped as \.

View more solutions

Comments

[romil gaurav]

Its giving me grep: illegal option -- F Also, \. is not working either.

[cuonglm]

@romhail: It's strange, what is your OS?

[A.L]

In order to answer to the question of cuonglm, you should add the version of grep in your question: what does grep --version return?

[Andrew Henle]

@A.L If his version of grep doesn't support -F, it's very likely to not support --version. -F is at least part of the POSIX standard, and the grep in question apparently doesn't support even that.

[marcelm]

Why would fgrep as a separate binary be faster than a non-regex codepath in grep -F?

[fvu]

@marcelm That is totally not what I said, on these old Unix (tm) systems these codepaths you mention were separate executables, the first utility I remember seeing that combined the three functionalities was GNU grep, somewhere in the nineties. GNU grep also had a far superior regex engine, compared to both the BSD and the SYSV derived commercial Unices of that time. The fact that OP's grep seems unable to understand -F might indicate that he's confronted with one of these dinosaurs, hence my suggestion to try fgrep - that's available in even very ancient Unices.

[OrangeDog]

@marcelm He means fgrep could be faster than grep. Neither the question nor this answer ever mention grep -F.