Running an interactive interpreter inside a python

[R. Bernstein]

castironpi <castironpi at gmail.com> writes:

> On May 15, 6:26 am, ro... at panix.com (R. Bernstein) wrote:
>> "Alan J. Salmoni" <salm... at gmail.com> writes:
>>
>> > I'm not sure if this is exactly what you're after, but try looking
>> > into the 'code' module.
>>
>> > It's fairly easy to make an interactive interpreter that runs within
>> > your program. If you import your programs variables into
>> > __main__.__dict__, you can have access to them which can be funky. You
>> > can even override the showtraceback method to catch various exceptions
>> > and do daft things like adding new methods to strings. I guess it
>> > would even be possible to have the commands compared to a list of
>> > commands and keywords to build a restricted interpreter, though how
>> > secure this would be against a determined attack is another matter.
>>
>> > Alan
>>
>> I think this (largely) does the trick. Thanks!
>>
>> I'm not sure about how to deal with globals yet which should come from
>> a stackframe f_globals. It might be possible to save and restore
>> __main__.__dict__ before and after the call to interact(). Probably
>> would have been cooler to design interact() to take a globals
>> parameter, same as eval does.
>>
>>
>>
>>
>>
>> > On May 15, 11:31 am, ro... at panix.com (R. Bernstein) wrote:
>> >> The next release of pydb will have the ability to go into ipython from
>> >> inside the debugger. Sort of like how in ruby-debug you can go into
>> >> irb :-)
>>
>> >> For ipython, this can be done pretty simply; there is an IPShellEmbed
>> >> method which returns something you can call. But how could one do the
>> >> same for the stock python interactive shell?
>>
>> >> To take this out of the realm of debugging. What you want to do is to
>> >> write a python program that goes into the python interactive shell -
>> >> without having to write your own a read/eval loop and deal with
>> >> readline, continuation lines, etc.
>>
>> >> The solution should also allow
>> >>  - variables/methods in the calling PYthon program to be visible
>> >>    in the shell
>> >>  - variables set in the interactive (sub) shell should persist after the shell
>> >>    terminates, although this is a weaker requirement. POSIX subshells
>> >>    for example *don't* work this way.
>>
>> >> There has been much written about how to embed Python from C, so I
>> >> suppose this may offer one way. And at worst, I could write
>> >> a C extension which follows how C Python does this for itself.
>>
>> >> But is there a simpler way?
>>
>> >> Thanks.- Hide quoted text -
>>
>> - Show quoted text -
>
> One threat is malicious code; sorry for this.

This is a little too cryptic for me. But then if we're talking
security, maybe obfuscation is in order. :-)

If this was meant as an explanation for why interact() only takes a
local parameter and none for global, security concerns are in fact why
you'd want to *add* that parameter: so that the caller could more easily
decide what interact sees as global. I haven't tried implementing a
__main__.__dict__ save, modify and restore around the interact(), but
I'll assume that this could be made to work.

If instead this was about the evils of writing a program that uses
code and calls interact, in general, debuggers and security are at
odds. In a highly secure environment, you probably want to disallow
any trace hook.  I think Ruby uses the global variable $SAFE with a
particular level setting for this purpose.