How do I use a " (quote) as a FOR /F delimiter in CMD.exe on Windows 7
Normally FOR options are enclosed within quotes. If you want to use a quote as part of an option, then the enclosing quotes must be ditched. That means all characters that the CMD interpreter uses as token delimiters must be escaped, including space and equal sign. Also the quote needs to be escaped.
for /f tokens^=2^ delims^=^" %%F in ...
This same technique is used to solve another common problem - how to use FOR /F and preserve the entire line, regardless what character starts a given line. The problem is the EOL option (semicolon by default). To guarantee preservation of the entire line, the EOL must be disabled. Here again the enclosing quotes are dropped and token delimiters must be escaped.
for /f delims^=^ eol^= %%F in ....
DELIMS is set to nothing because a space is never included in the DELIMS option unless it is the last option specified. The next option string character after EOL= is taken as the EOL character. But in this case there does not exist a next character because the space is not escaped, nor is it quoted. So the above syntax disables both DELIMS and EOL.
Quotes mark the boundaries of literal strings in which metacharacters are not parsed. This includes escape characters, typically the caret, so the second occurence of the double quotes cannot be escaped. Generally, the symbol that would mark the end of a literal string will always end the literal string.
If you want to prevent parsing of the "-character, you will have to escape it with an unquoted caret. Unfortunately, for's options string often has quite a lot of characters that need escaping and the legibility clearly suffers. Without using temporary files, the command would expand to:
for /F usebackq^ tokens^=2^ delims^=^" %i in (`findstr /I /R \.cpp\^" MyProj.vcxproj`) do @echo %i
Note that this will not produce correct results if the desired token is not the second. Further nesting of a for loop and a findstr command could easily correct that, but the syntax would be extremely dirty and may be beyond the scope of this question.