How to grep multiple strings on multiple files?

I am trying to grep multiple strings on multiple files. This is on Windows 7 x64, and I am using GNUWin32's flavor.

I have grep.bat with this command:

grep "string1\|string2\|string3\|string4" 20*.csv > out.csv

There's actually 68 strings, and they are 11 characters each, so the string within the quotes is 869 characters long (this includes the 2 character delimiters).

What is happening is I am getting an out.csv, but all it's doing is alternating between 0 bytes and a copy of my grep command! Huh? Why is grep searching a .bat file when I explicitly told it to check only files matching 20*.csv?

If I remove > out.csv and run the .bat again, then all I get is my command line repeated over and over in a command prompt window.

2 Answers

This works in my grep, it should work on any platform. What you want to do is read the patterns from a file. Here is an example (note the '-f-', i.e., read patterns from standard input (-):

$ man grep > grep.txt
$ man cat > cat.txt
$ cat > patterns
terminfo
full
should

(press Ctrl+D here)

$ cat patterns | grep -f- *.test
cat.test: The full documentation for cat is maintained as a Texinfo manual. If
cat.test: should give you access to the complete manual.
grep.test: This version number should be included in all bug reports (see
grep.test: should avoid both -q and -s and should redirect standard and
grep.test: implementations support \{ instead, so portable scripts should avoid {
grep.test: in grep -E patterns and should use [{] to match a literal {.
grep.test: portable scripts should avoid it.
grep.test: terminfo capability does not apply, when the chosen
grep.test: file name wildcard expansion and therefore should not be treated
grep.test: pcrepattern(3), terminfo(5), glob(7), regex(7).
grep.test: The full documentation for grep is maintained as a TeXinfo manual. If
grep.test: should give you access to the complete manual.

Use grep on Ubuntu on a VirtualBox VM and access the Windows host using VirtualBox's Shared Folders feature. This isn't the first bug I've found in GNUWin32's grep.