dig makes sure that the semi-colon is escaped for output purposes.
Now I have another tool, written in C/C++ that calls ns_sprintrr (from
libbind.a)
This does include the "\" before the semi-colon on EITHER TXT record
I have 2 questions:
1. is the "\" (slash) included in the wire format or is it stripped out?
2. what routine is dig using to print the record?
Thanks
--
Jack Tavares
Reminder: I am at GMT+2, 10 hours AHEAD of Seattle.
My workweek is Sunday-Thursday.
Email sent to me Thursday afternoon (PST) may not be viewed until Sunday
morning (GMT+2).
> Hello all -
>
> I am having a small problem.
>
> Given these 2 TXT records in a zone file
> isescaped TXT "escaped semi-colon\;"
> unescaped TXT "unescaped semi-colon;"
> (one has an escaped semi-colon, one has an UNescaped semi-colon)
>
> dig returns
>
> isescaped.test.net. 500 IN TXT "escaped semi-colon\;"
> unescaped.test.net. 500 IN TXT "unescaped semi-colon\;"
>
> dig makes sure that the semi-colon is escaped for output purposes.
>
> Now I have another tool, written in C/C++ that calls ns_sprintrr (from
> libbind.a)
> This does include the "\" before the semi-colon on EITHER TXT record
That's because both TXT records are essentially the same in that regard.
The last two characters of both are "n" and semicolon.
Semicolons don't require escaping when they're in quoted strings, but
it's OK to escape them anyway. A backslash simply causes the following
character to be treated as a constituent of the string. If that's its
normal meaning, the backslash is ignored. I think the only characters
that REQUIRE escaping in strings are double-quote (to prevent it from
terminating the string) and backslash itself (to prevent it from being
an escape). Maybe newline as well, but I'm not sure.
>
> I have 2 questions:
>
> 1. is the "\" (slash) included in the wire format or is it stripped out?
It isn't. The wire syntax is a counted string. There's no parsing
done, so no need for any escaping.
> 2. what routine is dig using to print the record?
Can't you read the source?
Did you mean to say 'This does NOT include the "\"' above?
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
>> 2. what routine is dig using to print the record?
>Can't you read the source?
Of course. Here is the call tree
printmessage() which calls
dns_message_sectiontotext() which calls
dns_master_rdatasettotext() which calls
rdataset_totext() which calls
dns_rdata_tofmttext() which calls
rdata_totext() which calls [via a 100 line switch statement
declared in a macro in an include file]
totext_txt() which calls
txt_totext()
which always prepends a "\" to a ";"
Can't imagine how I missed it the first time I looked.
It is unfortunate, in my opinion, that ns_sprintrr() does not follow the
same
logic that dig uses (or vice-versa).
Would it be unreasonable to request a change to ns_sprintrr() to prepend
the "\" ?
Thank you
> Would it be unreasonable to request a change to ns_sprintrr() to prepend
> the "\" ?
Why? As you noticed, the string is interpreted the same way with or
without the "\", so it's not needed.
A more serious problem would be if it fails to prepend "\" before
backslash or doublequote.
In article <fdtc77$1dfg$1...@sf1.isc.org>,
"Jack Tavares" <j.ta...@F5.com> wrote:
> Would it be unreasonable to request a change to ns_sprintrr() to
prepend
> the "\" ?
>Why? As you noticed, the string is interpreted the same way with or
>without the "\", so it's not needed.
For consistency of output. Dig output always prepends the "\".
I would think it would be nice if any client
that use ns_sprintrr() to get the same result that dig displays.
2 functions that do the same thing (more or less) should produce the
same output.
I think that is a worthy goal.
--
jack