Concatenating/inserting strings with backslashes

[Phil Mayers]

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.