[wd40bomber7]

I am writing LUA in a very difficult to use situation. The lua code exists essentially tacked on to another language as a means to generate information. Any lua code you write goes through several parses before it's finally spit out in its actual form in a temporary file where it is immediately executed.

This would actually not be an issue except somewhere along the line, one of those parsers messes up every % character. It treats it as the start of some special encoding I think. Anyways, by the time the lua code finally makes it into the temporary file all % characters and all the characters around them are terribly garbled. This is very unfortunate since a good chunk of the code uses string.format. There is no way to fix the parser(s) or I would have done so long before I came here.

Performance doesn't matter in the slightest. Neither does code size or anything like that. It just has to work. With this in mind I thought I would go find a snippet of code that decoded base64, and any strings that use % I would replace with the decoding function and the base64 representation of that string. That would have worked beautifully except for the minor fact all of the decoder functions I've found so far use string.format or the % somewhere in them.

Anyone have any better ideas?

This post has been edited by wd40bomber7: 05 June 2012 - 07:29 PM

[turboscrew]

So what are the other parsers?

I understood that the problem is that the "%"s do not "arrive" to LUA unchanged?

[ishkabible]

can you show the code? I've never heard of this happening as a bug(also, no intermediate file is created unless you explicitly tell it to)

do you mean like you have strings with stray '%' in them? you need to replace those with '%%' in the string before using format.

This post has been edited by ishkabible: 07 June 2012 - 02:28 PM

[wd40bomber7]

The following:

result = string.format('%s%s%s%s',result,string.char(lor(lsh(chars[1],2), rsh(chars[2],4))),(chars[3] ~= nil) and string.char(lor(lsh(chars[2],4), rsh(chars[3],2))) or "",(chars[4] ~= nil) and string.char(lor(lsh(chars[3],6) % 192, (chars[4]))) or "")

becomes this after its spit into the temporary file

result = string.format(',ÍwÀ¯‹Îè#þÿ‹Eü3ÿ;lj}ô‰}øŽ{

The other parsers aren't actually designed to parse LUA code, they parse the other language, their only actual job is to move the LUA code away from the other language and into a temporary file. Obviously the one responsible is failing at its job terribly. Unfortunately, as I mentioned earlier, there is nothing to be done. Instead I need to focus on some sort of circumvention mechanism. Such as a base 64 decoder that doesn't use the percent sign anywhere.

This post has been edited by wd40bomber7: 07 June 2012 - 07:30 PM

[ishkabible]

how are you creating a temporary file?