Bug - Fixed map_to_file and file_to_map do not work correctly with strings which contain "\n"

rlbond86

Member
map_to_file and file_to_map do not work correctly with strings which contain "\n"

KoLmafia's I/O functions fail with maps which contain strings with endline characters. Here's a little example:

Code:
boolean[string] m;
m["Hello\nGoodbye"] = true;
print("Original:");
foreach i in m
	print(i + ": " + m[i]);
map_to_file(m, "text.txt");
clear(m);
print("After load");
file_to_map("text.txt", m);
foreach i in m
	print(i + ": " + m[i]);

output:

Code:
> test1

Original:
HelloGoodbye: true
After load
Goodbye: true

contents of text.txt:

Code:
Hello
Goodbye	true

I believe that newlines should be escaped in some way by KoLmafia before output to avoid this issue. For now I am escaping them myself.
 
Is this a mafia bug or a Java feature?

\n is an escape code for "newline" like \r is an escape code for "return". They generally do the same thing but actually have different functions.

Have you tried \\n?
 
If it needs to become \\n, then map_to_file should save it as such... the two functions should be able to be used to move the data back and forth without affecting the specifics of that data.
 
I would love to hear if there is some combination of multi-escaping that works both ways; I never was able to figure it out (I am kinda slow though, so there may well be a way); ended up doing weird replacements along the lines of "OMGWTFTHISWASNEWLINE" when saving data... :p
 
I would love to hear if there is some combination of multi-escaping that works both ways; I never was able to figure it out (I am kinda slow though, so there may well be a way); ended up doing weird replacements along the lines of "OMGWTFTHISWASNEWLINE" when saving data... :p

PHP:
explode('<br />', nl2br($string));

Reminds me of this. Bane of my life in my last job.
 
Wait... NOW this is a mafia bug?

Well, technically I have no real authority on the matter. In my opinion, it's a bug, and I have provided a fix :)

If I were actively reading bug reports 18 months ago, I would've done the same.

Edit: To clarify my position on why I think it's a bug, Theraze puts things quite aptly.

the two functions should be able to be used to move the data back and forth without affecting the specifics of that data.

This wasn't the case, my patch addresses that.
 
Last edited:
JSONifying strings wouldn't be a bad idea (IMO), although again, it wouldn't be backwards compatible with anything containing backslashes.

For instance, that macro you posted in another thread would be JSONified as
Code:
"abort hppercentbelow 15\nsub mafiaround\nendsub#mafiaround\nsub mafiamp\ncall mafiaround; use 518\nendsub#mafiamp\n#mafiaheader\nif hasskill Chronic Indigestion\nwhile mpbelow 5\ncall mafiamp\nendwhile\nif hasskill 2\ncall mafiaround; skill 2\nendif\nendif"
 
That seems good to me.

map_to_file outputs the key & value fields of the structure you are dumping as TAB delimited strings, one line per entry. Therefore, both newline and tab (and backslash) characters need to be backslashed.

I suspect there are very few saved maps with strings containing backslashes. JSONifying strings would break those, but would be the (a) correct thing to do. Better than URLencoding them, which would break tons of saved maps - spaces turn into +, for example.
 
Revision 17532 escapes newlines, tabs, and backslashes as \n, \t, and \\ when you do map_to_file and does the reverse on file_to_map.

Existing files could not have newlines or tabs in the data fields, but they could have had backslashes - and this is not backwards compatible with such data fields.
 
Back
Top