On 09/11/12 15:39, Brian Candler wrote:
Here's something weird. I'm trying to concatenate some strings which contain
<backslash> <n> (i.e. not a newline).
Uh oh... here be dragons!
In a normal string literal, I have to enter four backslashes:
update reply {
Reply-Message := "a\\\\nb"
}
("\\n" gives a newline, "\\\n" gives backslash followed by newline)
Yeah; I think there is a similar thing happening here to the regexp
stuff I discussed on -devel recently.
I think what happens in the code is this:
1. lib/token.c:gettoken loads the config file and performs backslash
processing on any quoted strings
2. conffile.c:cf_pairtovp loads the VP update list at config load
time, and sets the "do_xlat" flag on any that are double-quoted
3. modcall.c:modcall calls radius_update_attrlist
4. evaluate.c:radius_update_attrlist checks the "do_xlat" flag on the
VP, which was set at config load, and calls expand_string (which calls
radius_xlat) followed by pairparsevalue.
The net effect is that:
update x {
Foo = "a\\\\n"
}
...is de-escaped many times:
* into "a<backslash><backslash>n" by the gettoken / config file loader
* into "a<backslash>n" by radius_xlat
* into "a<newline>" by pairparsevalue (on the result of radius_xlat)
This kind of thing is pretty common - exim has a similar problem. It's
difficult to know what to do about it in a manner that's universally
satisfactory.
One solution is to not process "\x" anywhere except loading from config
files, but that's likely a very significant backwards compatibility
break... you also might *want* to provide a way for people to interpret
escapes again (though this can be done with an xlat e.g.
"%{unescape:%{something-that-returns-backslash-n}}" == "<newline>"
Others options exist. Personally I find the existing behaviour quite
surprising, but it's also something I very seldom run into, so don't
worry too much about.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
