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

R

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.
 
Fluxxdog

Fluxxdog

Active member
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?
 
Theraze

Theraze

Active member
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.
 
StDoodle

StDoodle

Minion
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
 
bumcheekcity

bumcheekcity

Active member
StDoodle said:
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
Click to expand...

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

Reminds me of this. Bane of my life in my last job.
 
C

Catch-22

Active member
bordemstirs said:
Wait... NOW this is a mafia bug?
Click to expand...

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.

Theraze said:
the two functions should be able to be used to move the data back and forth without affecting the specifics of that data.
Click to expand...

This wasn't the case, my patch addresses that.
 
Last edited:
Veracity

Veracity

Developer
Staff member
Bump, although although URL Encoding strings is definitely nothing like backwards compatible.
 
H

heeheehee

Developer
Staff member
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"
 
Veracity

Veracity

Developer
Staff member
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.
 
Veracity

Veracity

Developer
Staff member
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.
 
You must log in or register to reply here.
Top