Escape paths with n

[res0nance]

Signed-off-by: Raihaan Shouhell raihaan.shouhell@autodesk.com

Looks like escaping windows paths does not work with \n

CC: @alexanderrtaylor

[alexanderrtaylor]

Thanks for looking at this @res0nance and the splitting of the string seems good to me. Tests are better than the ones I originally designed to capture windows specific paths

Strange that it didnt work before...

[mdres]

Tbh manually messing with the escaping at all seems like a bad idea. This PR definitely improves the situation though, because the weird re-escape behavior will trigger less often, but it will still actively screw up people that actually escape their paths correctly according to the Java Property format.

Since some people probably rely on the old behavior, maybe this PR can be improved further by trying to guess and exclude already escaped paths from the re-escaping (only touch things matching [A-z]:\\\\[^\\].* for example).

At least this behavior should be clearly documented. I just found this PR because I was wondering why our generated .property file with properly escaped umlauts (these things: ü, ö, ä) was injected incorrectly.

Property files can contain all kinds of things, \f, \t, \uXXXX, multi-line values, keys with escaped spaces and separators, all of which is handled by Property.load correctly if you play by the rules and correctly escape your inputs ;-)