https://bugzilla.wikimedia.org/show_bug.cgi?id=46294
--- Comment #5 from [email protected] --- (In reply to comment #4) > Lua just uses fwrite() on stdout, i.e. the FILE* supplied by the C library > called stdout. I don't think there is any way to change what mode it is in, > and > reopening it would be fairly complex. Agreed. I got as far as "io.stdout:write" in "MWServer:sendMessage" and assumed it was Lua. It makes more sense that it is the underlying C library / OS. > Note that "\r\n" might also be > converted > to \n by io.stdin:read() on the Lua side. I don't think this should be an issue as "encodeLuaVar" in "LuaStandaloneEngine.php" escapes "\r" and "\n" during serialization case 'string': return '"' . strtr( $var, array( '"' => '\\"', '\\' => '\\\\', "\n" => '\\n', "\r" => '\\r', "\000" => '\\000', ) ) . '"'; > Choosing a serialization format that does not use line endings would be one > way > around it. If I understand correctly, are you saying that "\n", "\r" should be escaped on the Lua side (in "recursiveEncode")? If so, I think this is theoretically best, though it may involve a performance hit, which would be especially unnecessary for Linux machines. > Converting line endings as appropriate if a Windows Lua binary is > detected would be another. I personally think this is best, at least for a short-term fix. "LuaStandaloneEngine.php" could detect the OS and apply the working fix if it is Windows. For what it's worth, I used a similar approach in my Java app. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
