Re: [Monotone-devel] RFC: lua output redirection

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Am 07.05.10 12:33, schrieb Stephen Leake:
>> Thomas Keller <address@hidden> writes:
>>> and secondly overwrites print() and io.write() at startup to use the
>>> new implementation.
>> 
>> I don't think this is a good idea; these are standard Lua functions that
>> are documented in the Lua manual. Better to introduce a new funciton
>> io.message or io.mtn_message. 
>
> We already have a couple of functions which behave differently, f.e. we
> have disabled os.execute and io.popen for security reasons. And not
> overwriting these two fails to resolve the original problem, i.e. having
> a dumb-save way to catch 90% of the implementors output.
>
>> On the other hand, I suppose it is reasonable in the mtn automate
>> stdio context to expect io.write() to show up in one of the stdio 
>> streams. I gather it does not now, but your change makes it do that.
>> 
>> But does it show up in the stdout or progress stream? Progress is
>> appropriate for debug messages, but someone will want to generate
>> basic_io from Lua, in the stdout stream; how do they do that?
>
> It would pop up in the progress (p) stream. I'm not sure how lua code is
> supposed to write basic_io to stdio's main output (m) stream. For
> non-stdio Lua implementors could still just call io.stdout:write()

Ok. If we make the assumption that anything written to io.write() is a
progress message, then I agree that capturing it somehow is more
important than the details of newlines and stdout vs stderr.

I think that assumption is reasonable; it's certainly true for my Lua
code.

Hmm. I'm not sure that's true in the current tests; does this
overwriting happen when the mtn tests are running?

If someone is depending on the current behavior, they can change to
io.stdout:write().

Sounds good.

-- 
-- Stephe