Why does this ‘findstr’ command not function as expected

command linefindstr

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?

Best Answer

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

Related Solutions

Bash Variables – Difference Between $myvar and “$myvar” in Bash

Different approach:

When you run git log --format="foo bar", those quotes aren't interpreted by git – they're removed by the shell (and protect the quoted text from splitting). This results in a single arg:

--format=foo bar

However, when unquoted variables are expanded, the results go through word-splitting, but not through unquoting. So if your variable contains --format="foo bar", it is expanded into these args:

--format="foo
bar"

This can be verified using:

```
printf '%s\n' $variable
```

...as well as any simple script which prints its received arguments.

#!/usr/bin/env perl
for $i (0..$#ARGV) {
    print ($i+1)." = ".$ARGV[$i]."\n";
}

#!/usr/bin/env python3
import sys
for i, arg in enumerate(sys.argv):
    print(i, "=", arg)

If you always have bash available, the preferred workaround is to use array variables:

myvar=( --format="foo bar" )

With this, the usual parsing is done during assignment, not during expansion. You use this syntax to expand the variable's contents, each element getting its own arg:

git log "${myvar[@]}"

Best Answer

Related Solutions

Bash Variables – Difference Between $myvar and “$myvar” in Bash

Related Question