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.