rlm_detail header not expanding \t

[Arran Cudbard-Bell]

> On 9 Sep 2015, at 22:22, Matthew Newton <mcn4 at leicester.ac.uk> wrote:
> 
> On Wed, Sep 09, 2015 at 01:41:51PM -0400, Alan DeKok wrote:
>> On Sep 9, 2015, at 12:30 PM, Matthew Newton <mcn4 at leicester.ac.uk> wrote:
>>> I just found that with correct_escapes set to false, it *does* work.
>> 
>>  Ugh.
> ...
>>  Now with a fix, and more test cases to catch this issue. :)  Try the v3.0.x branch.
> 
> Thanks - better than before, but not what I was expecting. Now "\"
> is always literal: "%t\t...", '%t\t...' with correct_escapes set
> to either true or false always outputs:
> 
>  Wed Sep  9 22:17:14 2015\t127.0.0.1

FWIW that's what I was expecting to happen - It's up to the consumer of the string to
translate those escape codes into something useful.

At the moment the xlat code uses the slashes to skip over parts of the string and temporarily
suspends their specialness, but does not consume the escape sequence.

This is why with the correct_escapes set you no longer have to do \\\\\\\\\\\\ to get \.

As a side effect:

	%{redis:{my special key}foobarbaz}

Actually needs:

	%{redis:{my special key%}foobarbaz}

To prevent that literal brace on the right, from being treated as the end of the expansion, and to unescape it.

If you do:

	%{redis:{my special key\}foobarbaz}

This would get passed to the redis func:

	{my special key\}foobarbaz

It fixes a whole bunch layered backslash problems, and puts the responsibility on the consumer of the expanded string, to translate it into the appropriate format.

So what's needed here is for linelog to interpret those backslash codes correctly.

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 872 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20150909/72533c9d/attachment.sig>