Haha, no I also didn't want to discredit Dave. He already mentioned it was untested. I corrected this for all the Google users who stumble upon this thread

Regards
aGerman

I updated my SO post: http://stackoverflow.com/a/8844873/1012053

I used to think that the Windows pipe operator appended <CR><LF> to the input if the last character in the stream was not a <LF>. But I've since discovered that FINDSTR is actually doing the alteration of the input.

FINDSTR also appends <CR><LF> to redirected input on Vista (and XP?) if the last character of the redirected file is not <LF>.

I've discovered a nasty FINDSTR "feature" running on Windows 7: it hangs indefinitely on Windows 7 if you search redirected input and the redirected file does not end with <LF>.


Dave Benham

How could I not see this before? I have so many doubts on using FINDSTR.

Added this page to my favs. Gonna read it when I've got enough time to.
Thanks, Dave.

XP also has the issue if the file does not end with appropriate line endings. It hangs.

I updated my SO FINDSTR post with two new sections:

1) Description of XP behavior displaying most control characters as dots

2) Bugged /S and /D options may fail to find files if short 8.3 names are encountered.


Dave Benham

Thanks.
I remember that the default is /R not /L.
Example:

print #
but

don't print anything. The default is /R not /L

I think you did not read the post carefully. It is more complicated than that.

I stated that the default for the /C option is literal.

The default for all other methods (anything other than /C option) depends on the content of the 1st search string. If the 1st search string contains an un-escaped meta character and the string is a valid regex, then all searches will be treated as regex. If the first string does not contain an un-escaped meta character, or if it is not a valid regex, then all search strings will be treated as literals.

The following is a regex search that matches because the first string is a valid regex that contains a meta character.

But this next example is a literal search that does not match because the first search string does not contain a meta character


Dave Benham

Thanks for the info.
When I specify /L or /R using the /C option, I get a message that says that the /C option was omitted.



Also, I have a dude with the /O option.
I have these file:

If I use:

it print:


The offset should be 3 not 0?

It seems buggy,

file.txt
d#dd
aaaa#aa#
all#everybody#is#ok
aaa

d:\ABC>findstr /O /c:"#" file.txt
0:d#dd
6:aaaa#aa#
16:all#everybody#is#ok

Here again, the correct information is already in my SO post.

Note - it is the byte offset of the beginning of the line that matches (measured from the beginning of the file), not the offset of the beginning of the match itself. Also, don't forget to count the CarriageReturn/LineFeed line terminators.

The /N and /O options specify the same locations within the file, but the /N option counts the number of lines, whereas the /O option counts the number of bytes. The /N option is 1 based, the /O option is 0 based.

So the results given by the Carlos and Foxidrive examples are corect/not bugged.


Dave Benham

I've updated my SO post to clarify the /O option;


Dave Benham

Thanks Dave.

That could be used to count the length of a line also, or several lines.

It was very confusing as you normally think of the character offset to be to a match of the regexp/literal. The description should say "prints file offset before each matching line."

/O Prints character offset before each matching line.

Cool idea foxidrive


I haven't figured out why I must subtract 3 instead of 2, but it appears to work.

Dave Benam