The Windows FINDSTR command is horribly documented. There is very basic command line help available through FINDSTR /?, or HELP FINDSTR, but it is woefully inadequate. There is a wee bit more documentation online at https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/findstr.
There are many FINDSTR features and limitations that are not even hinted at in the documentation. Nor could they be anticipated without prior knowledge and/or careful experimentation.
So the question is – What are the undocumented FINDSTR features and limitations?
The purpose of this question is to provide a one stop repository of the many undocumented features so that:
A) Developers can take full advantage of the features that are there.
B) Developers don’t waste their time wondering why something doesn’t work when it seems like it should.
Please make sure you know the existing documentation before responding. If the information is covered by the HELP, then it does not belong here.
Neither is this a place to show interesting uses of FINDSTR. If a logical person could anticipate the behavior of a particular usage of FINDSTR based on the documentation, then it does not belong here.
Along the same lines, if a logical person could anticipate the behavior of a particular usage based on information contained in any existing answers, then again, it does not belong here.
Preface
Much of the information in this answer has been gathered based on experiments run on a Vista machine. Unless explicitly stated otherwise, I have not confirmed whether the information applies to other Windows versions.
FINDSTR output
The documentation never bothers to explain the output of FINDSTR. It alludes to the fact that matching lines are printed, but nothing more.
The format of matching line output is as follows:
filename:lineNumber:lineOffset:text
where
fileName: = The name of the file containing the matching line. The file name is not printed if the request was explicitly for a single file, or if searching piped input or redirected input. When printed, the fileName will always include any path information provided. Additional path information will be added if the
/Soption is used. The printed path is always relative to the provided path, or relative to the current directory if none provided.Note – The filename prefix can be avoided when searching multiple files by using the non-standard (and poorly documented) wildcards
<and>. The exact rules for how these wildcards work can be found here. Finally, you can look at this example of how the non-standard wildcards work with FINDSTR.lineNumber: = The line number of the matching line represented as a decimal value with 1 representing the 1st line of the input. Only printed if
/Noption is specified.lineOffset: = The decimal byte offset of the start of the matching line, with 0 representing the 1st character of the 1st line. Only printed if
/Ooption is specified. This is not the offset of the match within the line. It is the number of bytes from the beginning of the file to the beginning of the line.text = The binary representation of the matching line, including any <CR> and/or <LF>. Nothing is left out of the binary output, such that this example that matches all lines will produce an exact binary copy of the original file.
The /A option sets the color of the fileName:, lineNumber:, and lineOffset: output only. The text of the matching line is always output with the current console color. The /A option only has effect when output is displayed directly to the console. The /A option has no effect if the output is redirected to a file or piped. See the 2018-08-18 edit in Aacini’s answer for a description of the buggy behavior when output is redirected to CON.
Most control characters and many extended ASCII characters display as dots on XP
FINDSTR on XP displays most non-printable control characters from matching lines as dots (periods) on the screen. The following control characters are exceptions; they display as themselves: 0x09 Tab, 0x0A LineFeed, 0x0B Vertical Tab, 0x0C Form Feed, 0x0D Carriage Return.
XP FINDSTR also converts a number of extended ASCII characters to dots as well. The extended ASCII characters that display as dots on XP are the same as those that are transformed when supplied on the command line. See the "Character limits for command line parameters – Extended ASCII transformation" section, later in this post
Control characters and extended ASCII are not converted to dots on XP if the output is piped, redirected to a file, or within a FOR IN() clause.
Vista and Windows 7 always display all characters as themselves, never as dots.
Return Codes (ERRORLEVEL)
/A:xxoption/Land/Rboth specified/A:,/F:,/C:,/D:, or/G:/F:fileor/G:filenot foundsee Regex character class term limit and BUG in part 2 of answer
Source of data to search (Updated based on tests with Windows 7)
Findstr can search data from only one of the following sources:
filenames specified as arguments and/or using the
/F:fileoption.stdin via redirection
findstr "searchString" <filedata stream from a pipe
type file | findstr "searchString"Arguments/options take precedence over redirection, which takes precedence over piped data.
File name arguments and
/F:filemay be combined. Multiple file name arguments may be used. If multiple/F:fileoptions are specified, then only the last one is used. Wild cards are allowed in filename arguments, but not within the file pointed to by/F:file.Source of search strings (Updated based on tests with Windows 7)
The
/G:fileand/C:stringoptions may be combined. Multiple/C:stringoptions may be specified. If multiple/G:fileoptions are specified, then only the last one is used. If either/G:fileor/C:stringis used, then all non-option arguments are assumed to be files to search. If neither/G:filenor/C:stringis used, then the first non-option argument is treated as a space delimited list of search terms.File names must not be quoted within the file when using the
/F:FILEoption.File names may contain spaces and other special characters. Most commands require that such file names are quoted. But the FINDSTR
/F:files.txtoption requires that filenames within files.txt must NOT be quoted. The file will not be found if the name is quoted.BUG – Short 8.3 filenames can break the
/Dand/SoptionsAs with all Windows commands, FINDSTR will attempt to match both the long name and the short 8.3 name when looking for files to search. Assume the current folder contains the following non-empty files:
The following command will successfully find all 3 files:
b.txt2matches because the corresponding short nameB9F64~1.TXTmatches. This is consistent with the behavior of all other Windows commands.But a bug with the
/Dand/Soptions causes the following commands to only findb1.txtThe bug prevents
b.txt2from being found, as well as all file names that sort afterb.txt2within the same directory. Additional files that sort before, likea.txt, are found. Additional files that sort later, liked.txt, are missed once the bug has been triggered.Each directory searched is treated independently. For example, the
/Soption would successfully begin searching in a child folder after failing to find files in the parent, but once the bug causes a short file name to be missed in the child, then all subsequent files in that child folder would also be missed.The commands work bug free if the same file names are created on a machine that has NTFS 8.3 name generation disabled. Of course
b.txt2would not be found, butc.txtwould be found properly.Not all short names trigger the bug. All instances of bugged behavior I have seen involve an extension that is longer than 3 characters with a short 8.3 name that begins the same as a normal name that does not require an 8.3 name.
The bug has been confirmed on XP, Vista, and Windows 7.
Non-Printable characters and the
/PoptionThe
/Poption causes FINDSTR to skip any file that contains any of the following decimal byte codes:0-7, 14-25, 27-31.
Put another way, the
/Poption will only skip files that contain non-printable control characters. Control characters are codes less than or equal to 31 (0x1F). FINDSTR treats the following control characters as printable:All other control characters are treated as non-printable, the presence of which causes the
/Poption to skip the file.Piped and Redirected input may have
<CR><LF>appendedIf the input is piped in and the last character of the stream is not
<LF>, then FINDSTR will automatically append<CR><LF>to the input. This has been confirmed on XP, Vista and Windows 7. (I used to think that the Windows pipe was responsible for modifying the input, but I have since discovered that FINDSTR is actually doing the modification.)The same is true for redirected input on Vista. If the last character of a file used as redirected input is not
<LF>, then FINDSTR will automatically append<CR><LF>to the input. However, XP and Windows 7 do not alter redirected input.FINDSTR hangs on XP and Windows 7 if redirected input does not end with
<LF>This is a nasty "feature" on XP and Windows 7. If the last character of a file used as redirected input does not end with
<LF>, then FINDSTR will hang indefinitely once it reaches the end of the redirected file.Last line of Piped data may be ignored if it consists of a single character
If the input is piped in and the last line consists of a single character that is not followed by
<LF>, then FINDSTR completely ignores the last line.Example – The first command with a single character and no
<LF>fails to match, but the second command with 2 characters works fine, as does the third command that has one character with terminating newline.Reported by DosTips user Sponge Belly at new findstr bug. Confirmed on XP, Windows 7 and Windows 8. Haven’t heard about Vista yet. (I no longer have Vista to test).
Option syntax
Option letters are not case sensitive, so
/iand/Iare equivalent.Options can be prefixed with either
/or-Options may be concatenated after a single
/or-. However, the concatenated option list may contain at most one multicharacter option such as OFF or F:, and the multi-character option must be the last option in the list.The following are all equivalent ways of expressing a case insensitive regex search for any line that contains both "hello" and "goodbye" in any order
/i /r /c:"hello.*goodbye" /c:"goodbye.*hello"-i -r -c:"hello.*goodbye" /c:"goodbye.*hello"/irc:"hello.*goodbye" /c:"goodbye.*hello"Options may also be quoted. So
/i,-i,"/i"and"-i"are all equivalent. Likewise,/c:string,"/c":string,"/c:"stringand"/c:string"are all equivalent.If a search string begins with a
/or-literal, then the/Cor/Goption must be used. Thanks to Stephan for reporting this in a comment (since deleted).If the
/c:stringor/g:fileoption is used, then the command will fail if the file name argument begins with-, even if quoted. This is because there is no search string argument, so the file name argument is then treated as an option. The easiest workaround is to prefix the file argument with dot backslash, as inSearch String length limits
On Vista the maximum allowed length for a single search string is 511 bytes. If any search string exceeds 511 then the result is a
FINDSTR: Search string too long.error with ERRORLEVEL 2.When doing a regular expression search, the maximum search string length is 254. A regular expression with length between 255 and 511 will result in a
FINDSTR: Out of memoryerror with ERRORLEVEL 2. A regular expression length >511 results in theFINDSTR: Search string too long.error.On Windows XP the search string length is apparently shorter. Findstr error: "Search string too long": How to extract and match substring in "for" loop?
The XP limit is 127 bytes for both literal and regex searches.
Line Length limits
Files specified as a command line argument or via the /F:FILE option have no known line length limit. Searches were successfully run against a 128MB file that did not contain a single <LF>.
Piped data and Redirected input is limited to 8191 bytes per line. This limit is a "feature" of FINDSTR. It is not inherent to pipes or redirection. FINDSTR using redirected stdin or piped input will never match any line that is >=8k bytes. Lines >= 8k generate an error message to stderr, but ERRORLEVEL is still 0 if the search string is found in at least one line of at least one file.
Default type of search: Literal vs Regular Expression
/C:"string"– The default is /L literal. Explicitly combining the /L option with /C:"string" certainly works but is redundant."string argument"– The default depends on the content of the very first search string. (Remember that <space> is used to delimit search strings.) If the first search string is a valid regular expression that contains at least one un-escaped meta-character, then all search strings are treated as regular expressions. Otherwise all search strings are treated as literals. For example,"51.4 200"will be treated as two regular expressions because the first string contains an un-escaped dot, whereas"200 51.4"will be treated as two literals because the first string does not contain any meta-characters./G:file– The default depends on the content of the first non-empty line in the file. If the first search string is a valid regular expression that contains at least one un-escaped meta-character, then all search strings are treated as regular expressions. Otherwise all search strings are treated as literals.Recommendation – Always explicitly specify
/Lliteral option or/Rregular expression option when using"string argument"or/G:file.BUG – Specifying multiple literal search strings can give unreliable results
The following simple FINDSTR example fails to find a match, even though it should.
This bug has been confirmed on Windows Server 2003, Windows XP, Vista, and Windows 7.
Based on experiments, FINDSTR may fail if all of the following conditions are met:
/Ioption)In every failure I have seen, it is always one of the shorter search strings that fails.
For more info see Why doesn’t this FINDSTR example with multiple literal search strings find a match?
Escaping Quote and Backslash within /G:FILE literal search strings
Standalone quotes and backslashes within a literal search string file specified by /G:file need not be escaped, but they can be.
"and\"are equivalent.\and\\are equivalent.If the intent is to find \\, then at least the leading backslash must be escaped. Both
\\\and\\\\work.If the intent is to find ", then at least the leading backslash must be escaped. Both
\\"and\\\"work.Escaping Quote and Backslash within /G:FILE regex search strings
This is the one case where the escape sequences work as expected based on the documentation. Quote is not a regex metacharacter, so it need not be escaped (but can be). Backslash is a regex metacharacter, so it must be escaped.
Character limits for command line parameters – Extended ASCII transformation
The null character (0x00) cannot appear in any string on the command line. Any other single byte character can appear in the string (0x01 – 0xFF). However, FINDSTR converts many extended ASCII characters it finds within command line parameters into other characters. This has a major impact in two ways:
Many extended ASCII characters will not match themselves if used as a search string on the command line. This limitation is the same for literal and regex searches. If a search string must contain extended ASCII, then the
/G:FILEoption should be used instead.FINDSTR may fail to find a file if the name contains extended ASCII characters and the file name is specified on the command line. If a file to be searched contains extended ASCII in the name, then the
/F:FILEoption should be used instead.Here is a complete list of extended ASCII character transformations that FINDSTR performs on command line strings. Each character is represented as the decimal byte code value. The first code represents the character as supplied on the command line, and the second code represents the character it is transformed into. Note – this list was compiled on a U.S machine. I do not know what impact other languages may have on this list.
Any character >0 not in the list above is treated as itself, including
<CR>and <LF>. The easiest way to include odd characters like<CR>and<LF>is to get them into an environment variable and use delayed expansion within the command line argument.Character limits for strings found in files specified by /G:FILE and /F:FILE options
The nul (0x00) character can appear in the file, but it functions like the C string terminator. Any characters after a nul character are treated as a different string as if they were on another line.
The
<CR>and<LF>characters are treated as line terminators that terminate a string, and are not included in the string.All other single byte characters are included perfectly within a string.
Searching Unicode files
FINDSTR cannot properly search most Unicode (UTF-16, UTF-16LE, UTF-16BE, UTF-32) because it cannot search for nul bytes and Unicode typically contains many nul bytes.
However, the TYPE command converts UTF-16LE with BOM to a single byte character set, so a command like the following will work with UTF-16LE with BOM.
Note that Unicode code points that are not supported by your active code page will be converted to
?characters.It is possible to search UTF-8 as long as your search string contains only ASCII. However, the console output of any multi-byte UTF-8 characters will not be correct. But if you redirect the output to a file, then the result will be correctly encoded UTF-8. Note that if the UTF-8 file contains a BOM, then the BOM will be considered as part of the first line, which could throw off a search that matches the beginning of a line.
It is possible to search multi-byte UTF-8 characters if you put your search string in a UTF-8 encoded search file (without BOM), and use the /G option.
End Of Line
FINDSTR breaks lines immediately after every <LF>. The presence or absence of <CR> has no impact on line breaks.
Searching across line breaks
As expected, the
.regex metacharacter will not match <CR> or <LF>. But it is possible to search across a line break using a command line search string. Both the <CR> and <LF> characters must be matched explicitly. If a multi-line match is found, only the 1st line of the match is printed. FINDSTR then doubles back to the 2nd line in the source and begins the search all over again – sort of a "look ahead" type feature.Assume TEXT.TXT has these contents (could be Unix or Windows style)
Then this script
gives these results
Searching across line breaks using the /G:FILE option is imprecise because the only way to match <CR> or <LF> is via a regex character class range expression that sandwiches the EOL characters.
[<TAB>-<0x0B>]matches <LF>, but it also matches <TAB> and <0x0B>[<0x0C>-!]matches <CR>, but it also matches <0x0C> and !Note – the above are symbolic representations of the regex byte stream since I can’t graphically represent the characters.
Answer continued in part 2 below…