> If I understand you, you have a python cmdline app that does something > useful. You have users who aren't comfortable with the command line, so > you are writing a GUI wrapper that calls the cmdline app with popen(). That is correct
> A better approach is to turn the functional part of the cmdline app - > the code that does the real work - into an importable module. it already is importable >>Then your GUI app can import and use this module directly, instead of doing hacks > with popen() and stdout. This all worked fine, until the author of the cmd line app stopped using stdout and started using the logging module. Now I cannot capture any output from his module. > You don't even need a separate module for the cmdline app if it is > written correctly - the command-line-specific part can be in an main() > function that is only called if the module is run as main. not totally true. It must be a stand-alone app, because there are people using it now and many don't want to use the gui. It is maintained completely independent of the gui by people other than myself.. Any changes in the cmdline app should not affect the gui. That was the intent by the author anyway. The use of the logging module happens to be an exception to this. Using popen() in a thread was a nice clean way to capture it's output. Perhaps the exec/eval isn't so clean it's just what first came to mind. I've already switched the exec/eval code to the import style. _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor