Unfortunately, you are probably up against a known deficiency in the print()
function, which is really intended for quick and dirty debugging at a console prompt, and is missing some necessary flexibility.
The base library function print()
implemented by luaB_print()
in lbaselib.c explicitly uses the C runtime's stdout
stream as its destination. Since it refers to the global variable stdout
explicitly in its implementation, the only way to redirect it is to cause that file handle to be redirected. In a C program that can be done by calling freopen(stdout,...)
. Unfortunately, there isn't a stock library function in Lua that can do that.
The io
library is implemented in liolib.c. It uses the function environment to hold a table of open file descriptors, and during its initialization it creates file
objects named io.stdin
, io.stdout
and io.stderr
for the three standard descriptors. It also provides functions named io.output
and io.input
to allow those two descriptors to be modified to point to any open file
object (or a newly opened file if a file name is passed). However, those functions only change the function environment table and do not call freopen()
to modify the C runtime's table of FILE
values.
I have no idea how LuaInterface attempts to treat the standard C runtime's idea of stdout
. It may very well be that stdout
is not connected to anything useful in the VS debugger because it probably takes advantage of some .NET feature to capture output from the module being debugged that may not be all that compatible with C in any case.
That said, it is easy to replace the standard print
function. Just use existing features of LuaInterface to write a global function named print
that calls tostring()
on each argument and passes it to the whatever .NET things is the standard output device.