i'm sorry, but i'm sure that this is not a bug in findstr.
Somewhen in 2001 or 2002 i have read how findstr handles redirected input within the XP dos shell - it's long ago, so i can't remember the link address; and i havn't found it in actual MSDN - sry for that - but i'm sure that it was described in this way:
The program findstring expects full lines (cpp-style: "String\r\n", where \r is a carriage return char and the\n is a new line char) on redirected input.
If findstr does not get, what is assumed, it may be of one of these reasons:
reason 1) the delivering process/thread may have crashed for what reasons ever, or
reason 2) all was ok, just forgotten the "\r\n".
The error handling is as follows on piped data (using |):
It is assumed that nobody needs a string search on a single character, so if one character is read, it is assumed that reason 1) is the cause; to avoid errors the execution is aborted (for this last char).
On 2 or more chars it is assumed, that reason 2 is the cause, so execution is not interrupted.
(Ms uses findstr on 2 char strings, and never on 1 char strings, so this is their limit.)
((for /l %i in (0,1,9) do @echo:Line_%i.)&set/p"=x"<nul)|findstr "^"
((for /l %i in (0,1,9) do @echo:Line_%i.)&set/p"=x "<nul)|findstr "^"
Btw, for file redirection (findstr "^" < file.txt) the following is assumed:
Files that contain input are valid (\r\n at the end of every file), and files may be too huge to be read in one single disk read access.
So it is assumed that the input file reader takes just some time to provide the next characters.
This may result in an infinit loop, if the file is not valid.
So validating such files is recommended.
This is all that i remember, i try to find (and post/link the full article) it.