1

Given the following piped in text:

a master
a release
a release2
a some-release

Can someone please explain why

findstr /i /r /c:"a release$"

does not return line 2?

After several hours of reading everything imaginable about the windows findstr command, it just doesn't seem possible to get the $ character to match the EOL. Note that using the /E switch instead of $ makes no difference. I am running Windows 7.

Can someone come up with any way to match just line 2 using standard windows commands? I will resort to grep if necessary, but I can't believe there's no way to solve this natively.

Thanks!

Rob Oaks
  • 189
  • 2
  • 11
  • 2
    Of course this isn't a real answer, but in my experience `findstr` is just not worth the pain. You [can tabulate all the weirdo behavior](http://stackoverflow.com/a/8844873/214671), but in the end installing the GNU coreutils is going to take away a lot of frustration. – Matteo Italia Oct 30 '14 at 06:55

3 Answers3

4

You mention "piped" text. I just had this problem and was searching on stack. The answer for me was, findstr /R and the echo command have some weird quirks with pipes in DOS (or cmd).

I was trying to match files ending in .jpg, so to test, my command was:

    echo  "myfile spaces in name.jpg" | findstr /i /r "\.jpg$"

But that wasn't working. I used gnu utils to find out, echo with a space before the pipe inserts a SPACE in the output of the PIPE. Since I'm very used to UNIX style echo and regular expressions I did not expect the extra space inserted after the filename in my echo test.

To fix, I added a " *" (space-star) in the regex after the jpg, (to match 0 or more spaces):

    echo  "myfile spaces in name.jpg" | findstr /i /r "\.jpg *$"

That worked great.**

Proof using GNU's octal dump command (space is 040 in octal):

    c:\>echo "myfile.jpg" | od -cb
    0000000   "   m   y   f   i   l   e   .   j   p   g   "      \r  \n
            042 155 171 146 151 154 145 056 152 160 147 042 040 015 012

Now if I remove the space before the "|" pipe, it goes away:

    c:\>echo "myfile.jpg"| od -cb
    0000000   "   m   y   f   i   l   e   .   j   p   g   "  \r  \n
            042 155 171 146 151 154 145 056 152 160 147 042 015 012

This shouldn't happen in text files in DOS, nor most commands filtered through a pipe, but it will happen if you do quick command line tests using echo like I did.

** Another weird quirk (at least on my Win10 version of findstr), it ignores double-quotes near the end of the line.

dbeasy
  • 61
  • 3
2

If there are not non visible characters in the data, the most probable cause is the line termination character. If the lines piped do not end with carriage return / line feed (0x0D 0x0A) characters, findstr will not match the end of the line where it should.

Try something like

sourceofdata | more | findstr /r /c:"a release$"
sourceofdata | find /v "" | findstr /r /c:"a release$"

Both find and more changes the line ending. If it works, you have found the source of the problem.

If not, here (if you have still not readed it) you will find an extensive documentation on how findstr can fail.

Community
  • 1
  • 1
MC ND
  • 69,615
  • 8
  • 84
  • 126
  • I'd suggest closely examining the output of the prior process by redirecting to a file and using a decent hex editor. Some utilities insert spaces and then backspaces in the text. Others generate LF only, not CRLF. Others use even stranger combinations - a space at the end of the line could also be suspected. And beware the unterminated-last-line also. – Magoo Oct 30 '14 at 07:48
  • @Magoo, Sorry, i forget a `not` in the text. Thank you. There is a long list of things that will make `findstr` fail, both in the data and in the program itself. This is just the must *probable* cause and a way to determine if it is the case. – MC ND Oct 30 '14 at 08:02
  • @MCND was correct. The problem was indeed the EOL character, as I suspected. What I didn't know was that using `more` (or `find`) would correct the line endings. The swiftness of your reply is much appreciated. – Rob Oaks Oct 30 '14 at 12:59
0

It won't work. /c says do literal not regular expresion. You can make it work with command line switches though. Did you look up the reference before writing your command.

  • Wrong - The /R (regular expression) option overrides the default literal interpretation of the /C:"string" option. – dbenham Oct 30 '14 at 11:23