0

It's not a very clear question, because it's not very easy to explain what's going on. I'm going through a DNS zone file and looking for records that don't match what's in the file. I'm reading the file line-by-line, and separating each line into its 2 fields (hostname & IP).

My issue is that when I do the comparison, the IP that's pulled from the line field is full of escapes.

   #!/bin/bash -x

   inFile='./testrecords'
   while IFS=' ' read -r hostName fileIP
   do

Then I do some stuff to get the actual IP address from AWS. The issue occurs in the following comparison:

   if [[ "$actualIP" != "$fileIP" ]] ; then
       echo "$hostName $fileIP" >> recordstodelete
       gsed -i "/$hostName/d" $inFile
   fi

And here's the result (followed through the script by adding -x):

+ actualIP=10.238.4.234
 ]][ 10.238.4.234 != \1\0\.\2\3\8\.\4\.\2\3\4\

I've attempted to pass that variable through sed, to get rid of the \'s, but that had no effect. I've changed the brackets in the comparison to single brackets (thinking maybe regex expansion had something to do w/it), which produced a different, but still incorrect output:

   if [ "$actualIP" != "$fileIP" ] ; then
       echo "$hostName $fileIP" >> recordstodelete
       gsed -i "/$hostName/d" $inFile
   fi

Produces:

+ actualIP=10.238.4.234
+ '[' 10.238.4.234 '!=' $'10.238.4.234\r' ']'

The other oddness is that $fileIP is passed correctly, without issue in the ensuing echo statement.

Travis
  • 404
  • 1
  • 4
  • 14
  • 1
    Your file has DOS/Windows carriage return line endings (as evidenced by the trailing `\r`). See the duplicate for ways to strip them – that other guy Feb 11 '20 at 22:01
  • The escapes are just an oddity of how bash displays the right side of a `=` or `!=` test inside `[[ ]]`. It splatters escapes before characters to indicate they're being matched as literal characters rather than wildcards (which is because of the double-quotes around the variable reference). **This is what you want**, not an indication of a problem. As @thatotherguy says, the actual problem is the trailing carriage return, probable because of a DOS/Windows-format file. – Gordon Davisson Feb 12 '20 at 00:48

0 Answers0