dig ptr parsing issue

[mrballcb]

On my (Ubuntu 9.10) box, when I do a dig -x, the output looks as expected, however the formatting appears to be a bit off in one spot:
;; ANSWER SECTION:
1.0.0.0.0.8.0.0.0.1.0.0.0.0.0.0.5.0.0.0.3.0.0.0.8.b.7.0.1.0.0.2.ip6.arpa. 86400IN PTR amimpact-v6.bip.bit.nl.

Notice how there is no space between the TTL and the word IN.  I don't know if this is a bug with a specific version of bind utils, or if this is a bug due to the output formatting not expecting such a long answer, or something else.

In the daily part of the certification section, could you adjust the dig ptr parsing to make that space optional?  The dig output fails when I paste it as-is, but if I put a space between the TTL and "IN", then it passes.

Regards...           Todd

[jimb]

The output of dig appears to use spaces in some places, and tabs in other places.  Depending on the terminal you use, and the width of your terminal, it looks like it sometimes compresses the tab to nothing!  When I make my xterm wide, it shows up fine.  When it's 80 columns, there's no space.

1.0.0.0.0.8.0.0.0.1.0.0.0.0.0.0.5.0.0.0.3.0.0.0.8.b.7.0.1.0.0.2.ip6.arpa. 85486\tIN PTR amimpact-v6.bip.bit.nl.  \n

I imagine a script would parse this correctly anyway, since the tab would be a field delimiter.  Plus, they're probably using "+short" which gets rid of the problem all together.

An interesting thing you found there though.

EDIT:

Where it puts the tabs also appears to vary and is apparently output dependent:
;; ANSWER SECTION:\n1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.3.3.8.0.7.4.0.1.0.0.2.ip6.arpa. 45 IN\tPTR ipv6.jsbc.cc.\n\n

Note here it put it between the IN PTR, and not right after the TTL like it did for yours.  Too bad there isn't a flag to dig that just makes it do simple ASCII or some sort of RAW printout.  Easy enough to convert tabs to spaces though with something like "sed -e 's/\t/ /g'" if you must.

[mrballcb]

Heh.  In other words, "I'm a big boy, fix it myself" :-D

[snarked]

Note that in the original query of this thread, the tab character appeared at position 80.  In an 80-character-wide screen, where is it supposed to tab to?

[jimb]

Heh.  In other words, "I'm a big boy, fix it myself" :-D

I noticed this too when I was doing the daily stuff, and made it work by running a extra wide (160 column) xterm when I did it.  Worked for me.  Could also blow it through sed like I did above, but I found it easier just to open a big xterm.  :P

Note that in the original query of this thread, the tab character appeared at position 80.  In an 80-character-wide screen, where is it supposed to tab to?

Weird eh?  Not sure what's going on here in dig.