castironpi <[EMAIL PROTECTED]> writes: > On May 15, 6:26 am, [EMAIL PROTECTED] (R. Bernstein) wrote: >> "Alan J. Salmoni" <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] (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. -- http://mail.python.org/mailman/listinfo/python-list
