Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
what OS are you using? – EBGreen Oct 24 '12 at 15:20
Windows 7. Plain ol' Command Prompt (i.e. no PowerShell). – CubicleSoft Oct 24 '12 at 15:23
I'll check it out, but why not use PS? – EBGreen Oct 24 '12 at 15:24
The tools of the basic Command Prompt are generally sufficient for my needs. – CubicleSoft Oct 24 '12 at 15:28
up vote 4 down vote accepted

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:"\"^>" *
share|improve this answer
This works fine. – Karan Oct 24 '12 at 23:02
+1 for the link to the extensive MSDN blog post. Marking as the answer because this works. – CubicleSoft Oct 25 '12 at 4:09

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:""^>" *.

share|improve this answer
findstr /sic:""^>" * does not work in Win7! Did you try it yourself? – Karan Oct 24 '12 at 23:01
How does the command behave on your system? I indeed tried it myself, on a Windows 7 machine and can confirm it does work. – Marcks Thomas Oct 24 '12 at 23:13
Win7 x64, created a bunch of text files, a few had "> in them while the rest didn't. Ran your command and just got a blinking cursor at the next line, as if it was waiting for input. I could type whatever I wanted, press Enter multiple times, but the only way back to the cmd prompt was via Ctrl+C/Break. No output at all. – Karan Oct 24 '12 at 23:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .