python - 从 Python 启动另一个程序>单独<

Question

我正在尝试从 Python 运行一个外部的、独立的程序。通常不会有问题，但该程序是一个游戏，并且内置了 Python 解释器。当我使用 subprocess.Popen 时，它会启动单独的程序，但会在原始程序的 Python 实例下启动，以便它们共享第一个 Python 控制台。我可以很好地结束第一个程序，但我宁愿有单独的控制台(主要是因为我隐藏了控制台开始，但是当我使用 subprocess.POpen 从 Python 启动程序时它会显示出来)。

如果我可以完全独立地启动第二个程序，我会很高兴，就像我只是“双击它”一样。此外， os.system 将无法工作，因为我的目标是跨平台兼容性，而这仅在 Windows 上可用。

Answer 1

I would like it if I could start the second program wholly on its own, as though I just 'double-clicked on it'.

从 2.7 和 3.3 开始，Python 没有跨平台的方式来做到这一点。全新 shutil.open将来可能会添加方法(可能不在该名称下)；见 http://bugs.python.org/issue3177详情。但在那之前，您必须为您关心的每个平台编写自己的代码。

幸运的是，与 shutil.open 相比，您要做的事情更简单、更通用。最终希望提供，这意味着编码并不难:

在 OS X 上，有一个命令叫 open 这正是您想要的:“打开命令打开一个文件(或目录或 URL)，就像您双击文件的图标一样。”所以，你可以只popen open /Applications/MyGame.app .

在 Windows 上，等效命令是 start ，但不幸的是，这是 cmd.exe 的一部分shell 而不是一个独立的程序。幸运的是，Python 自带了一个函数 os.startfile 做同样的事情，所以只是 os.startfile(r'C:\Program Files\MyGame\MyGame.exe') .

在与 FreeDesktop 兼容的 *nix 系统(包括大多数现代 linux 发行版等)上，有一个非常相似的命令，名为 xdg-open :“xdg-open 在用户的首选应用程序中打开文件或 URL。”再次，只是 popen xdg-open /usr/local/bin/mygame .

如果您希望在其他平台上运行，则需要进行一些研究以找到最佳的等价物。否则，对于 Mac 和 Windows 以外的任何东西，我只会尝试 popen xdg-open ，如果失败则抛出错误。

见 http://pastebin.com/XVp46f7X对于(未经测试的)示例。

请注意，这仅适用于运行实际上可以在 Finder/Explorer/Nautilus/等中双击启动的内容。例如，如果您尝试启动“./script.py”，根据您的设置，它可能会启动一个包含您的脚本的文本编辑器。

此外，在 OS X 上，您希望运行 .app 包，而不是其中的 UNIX 可执行文件。 (在某些情况下，启动 UNIX 可执行文件——无论是在 .app 包内还是独立的——可能会起作用，但不要指望它。)

另外，请记住，以这种方式启动程序与从命令行运行程序不同——特别是，它将从 Windows/Launch Services/GNOME/KDE/继承其环境、当前目录/驱动器等。等等。 session ，而不是来自您的终端 session 。如果您需要对子进程进行更多控制，则需要查看 open 的文档。 , xdg-open , 和 os.startfile和/或提出不同的解决方案。

最后，只因 open/ xdg-open/ os.startfile成功实际上并不意味着游戏正常启动。例如，如果它在甚至可以创建窗口之前启动然后崩溃，对您来说它看起来仍然是成功的。

你可能想在 PyPI 周围寻找可以做你想做的事的库。 http://pypi.python.org/pypi/desktop看起来有可能。

或者您可以查看 issue 3177 中的补丁，然后选择您最喜欢的补丁。据我所知，它们都是纯 Python，您可以轻松地将添加的函数放在自己的模块中，而不是在 os 中。或 shutil .

作为一个快速的黑客，你可以(ab)使用 webbrowser.open . “请注意，在某些平台上，尝试使用此功能打开文件名可能会起作用并启动操作系统的关联程序。但是，这既不支持也不可移植。”特别是 IIRC，它不适用于 OS X 10.5+。但是，我相信从文件名中创建 file: URL 实际上适用于 OS X 和 Windows，并且也适用于大多数(但不是全部)配置的 linux。如果是这样，它可能足以用于快速而肮脏的脚本。请记住，它没有被记录在案，它可能会损坏您的某些用户，将来可能会损坏，并且它被 Python 开发人员明确认为是滥用，所以我不会指望它会更严重。并且它会在启动“script.py”或“Foo.app/Contents/MacOS/foo”、传递环境变量等时遇到与上述更正确方法相同的问题。

您问题中的几乎所有其他内容都无关紧要且错误:

It wouldn't be a problem normally, but the program is a game, and has a Python interpreter built into it.

那没关系。如果游戏从 C 代码写入标准输出，它会做完全相同的事情。

When I use subprocess.Popen, it starts the separate program, but does so under the original program's Python instance

不，它没有。它启动了一个全新的进程，其嵌入式 Python 解释器是一个全新的 Python 实例。例如，您可以通过运行与游戏嵌入的不同版本的 Python 来验证这一点。

so that they share the first Python console.

不，他们没有。它们可能共享相同的 tty/cmd 窗口，但这不是一回事。

I can end the first program fine, but I would rather have separate consoles (mainly because I have the console start off hidden, but it gets shown when I start the program from Python with subprocess.POpen).

您始终可以将子进程的 stdout 和 stderr 通过管道传输到例如日志文件，然后您可以根据需要将其与父进程的输出分开查看。但我认为这是一个切线，与您真正关心的无关。

Also, os.system won't work because I'm aiming for cross-platform compatibility, and that's only available on Windows.

错误的; os.system 可在“Unix、Windows”上使用——这可能是您关心的任何地方。但是，它不起作用，因为它使用相同的 tty 在脚本的子 shell 中运行子程序。 (而且它还有很多其他问题——例如，阻塞直到 child 完成。)