On 9 Sep 2015, at 22:22, Matthew Newton <mcn4@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@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@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2