Why grep matches all lines no matter what pattern

I have a problem with grep. I have a http://pastebin.com/HxAcciCa file that I want to check for specific templates. And when I try to find it, grep returns all the lines, provided that the template already exists in the given file.

To explain more, this is the code I'm running

grep -F "ENVIRO" "$file_pos" >> blah 

No matter what else I try, even if I provide the whole line as a bash template, it always returns all the lines.
These are variations of what I'm trying:

 grep -F "E20" "$file_pos" >> blah grep E20 "$file_pos" >> blah grep C:\E20-II\ENVIRO\SSNHapACS480.dll "$file_pos" >> blah grep -FC:\E20-II\ENVIRO\SSNHapACS480.dll "$file_pos" >> blah 

Also, for some strange reason, when you add the -x option to grep, it does not return any string, despite the fact that there is an exact pattern.

I searched the web and bash documentation for this reason, but found nothing.

My last test was as follows

 grep -F -C 1 "E20" "$store_pos" >> blah #store_pos has the same value as $file_pos 

I thought that maybe it was printing lines after the result, but it wasn’t. I used the blah file to see the result. I also use Linux mint rebecca. Finally, although the naming is pretty familiar, this question is not like Why grep matches all the lines for the pattern "\ '"

And finally, I would like to say that I am new to bash. I suspect that the error may be related to the main file http://pastebin.com/HxAcciCa , and not to the code?

+6
source share
3 answers

From the comments you can see that the file has a carriage return that limits lines, not lines waiting for grep ; as a result, grep sees the file as one huge line that either matches or doesn't match the goal as a whole.

(Note: there are at least three different conventions on how to separate lines in a "plain text" file - unix uses a new line ( \n ), DOS / Windows uses a carriage return followed by a new line ( \r\n ), and on versions of MacOS using OS prior to OSX, only carriage return ( \r ) was used.)

I don’t understand how your file ended up in this format, but you can easily fix it:

 tr '\r' '\n' <badfile >goodfile 

or "on the fly":

 tr '\r' '\n' <badfile | grep ... 
+2
source
  • Check the line endings in your input file: file , wc -l .
  • Make sure you really use the correct grep : which grep .
  • Use > to redirect output or | more | more or | less | less so as not to confuse previous attempts you add.

Edit: It looks like your file has invalid line endings (possibly old Mac OS ( CR )). If you have dos2unix , you can try converting them to the end of a Unix-style ( LF ) line.

+2
source

I don’t have access to a PC at the moment, but that can help you troubleshoot: 1. Use grep -color -F to make sure it matches correctly. 2. After your application, use | cat -A, to see if there are any awesome control characters, lines must end with $, any other characters like \ I or \ M can sometimes be a headache.

I suspect number 2 looks like Windows exit. In this case, you can cat filename | dos2unix | grep stmt should solve it

Have you saved dos2unix output as another file? Just double check the file, it should look like this:

 [ root@pro-mon9001 ~]# cat -A Test.txt Windows^M$ Style^M$ Files^M$ Are^M$ Hard ^M$ To ^M$ Parse^M$ [ root@pro-mon9001 ~]# dos2unix Test.txt dos2unix: converting file Test.txt to Unix format ... [ root@pro-mon9001 ~]# cat -A Test.txt Windows$ Style$ Files$ Are$ Hard$ To$ Parse$ 

Now it should parse correctly - so just make sure it converted the Good luck file correctly!

+1
source

Source: https://habr.com/ru/post/988277/


All Articles