Why does this 'findstr' command not function as expected?

Question

I use the command-line program 'findstr' frequently as I write software. It helps me quickly locate all the files that contain a specific string in a set of subdirectories. It is a lot faster to use 'findstr' than anything else in a lot of cases. Today I ran into an issue where I wanted to find the string ">, so I ran this command (what I considered to be a fairly typical escaped string):

findstr /sic:"\">" *

And got back this cryptic error message: "The filename, directory name, or volume label syntax is incorrect."

Changing it to:

findstr /sic:'\">' *

Works properly. Why did I need to use single quotes instead of double quotes? I've run hundreds (maybe thousands?) of findstr commands before where I've escaped double quotes inside a double quote wrapper without any issue. What makes this particular search string so different?

Answer 1

There are two levels of processing going on here - first cmd.exe is parsing the command line to determine if redirection, etc needs to happen, and then after that, findstr gets the remaining command line and does its own parsing according to its own rules (in practice, usually the same for various programs).

This MSDN blog post goes into some detail on the subject.

It seems to me that, since > is a cmd.exe metacharacter, what you need is the cmd.exe escape character, which happens to be ^. For example, this command works for me:

findstr /sic:"\"^>" *

Answer 2

The character > is used for redirection and generally needs to be escaped with a caret if part of a literal string. Encapsulating the string in quotes will prevent metacharacters from being parsed and eliminates the need for escaping. That's why both echo ">" and echo ^> will print an actual greater than-sign instead of trying to redirect the output.

The second occurence of double quotes always marks the end of a literal string. It cannot be escaped, because the caret would not be parsed as a metacharacter; it is in between quotes. As a result, both echo "">" and echo "^">" will try to redirect the output, in this case to an invalid file.

In your first line, findstr /sic:"\">" *, the second double quotes are interpreted as the end of a literal string. The next character indicates a redirected output. The succeeding filename is indeed invalid; the error thrown is hardly cryptic. The remainder of the intended argument isn't even visible to the findstr-command, which only gets to execute /sic:"\". If you want to stick to double quotes, the following syntax would behave as intended: findstr /sic:""^>" *.