Item9871: Escaped new lines lose their escape when rendered in macro if inside SEARCH $pattern

A bug spun off from Item9867

See this example which is self contained.

First some data to find

• dubtest1
• dubtest2

Then a macro set to a regex search (see raw data to see it)

• Set DROPDOWN = dubtest1 dubtest2

And now below we see the DROPDOWN macro

dubtest1 dubtest2

All looks find after I fixed Item9867.

But we have bug lurking. When the DROPDOWN is expanded into a search again the escaped * is escaped by \\ but the newline is not. I see an inconsistancy lurking that I want to find out what is. I think things work by chance right now because the pattern works with a real newline instead of \n.

-- KennethLavrsen - 23 Oct 2010

This seems like normal Macro expansions.

Maybe there is no problem in practical because we interpret a literal newline correctly in the next step.

• Set TESTMACRO = START[\n] [\\n] \nEND

START[
] [\n] 
END

It is clear to see from the result that all escapes are unescaped one level.

I need to study this more but I may very well end up declaring this a feature and no action this

-- KennethLavrsen - 23 Oct 2010

The replacement of \n to newline happens in lib/Foswiki/Prefs/BaseBackend in sub cleanupInsertValue. This is where we clean up the preferences as we load them. Ie when we set the value of the macro.

I have traced this all the way back to (tm)wiki release Cairo where ..Prefs.pm sub _insertPrefsValue did the exact same

So it is well proven to work. So no good idea to change this.

Item9867 failed because the untaint code could not do multiline and that is fixed now.

No action needed

-- KennethLavrsen - 23 Oct 2010

Commenting is disabled while not logged in