0

由于某些需要，我被迫更正os.environ['PATH']以能够运行dir\to\fake\python.cmd脚本，该脚本在执行之前向原始参数添加了一些额外的参数。

我还有两个 python 脚本：

测试1.py：

# ...
p = subprocess.call("test2.py")   # shell=True works fine
# ...

测试2.py：

# ...
print "Hello from test2.py"
# ...

当我运行python test1.py我的“假”python.cmd做它的东西时，指的是原始 pythonc:\Python25并test1.py使用我的额外参数运行。但是，遗憾的test2.py是，脚本从未被调用。如果我把shell=True作为subprocess.call论点 - 一切都很好，test2.py被称为。

我知道，默认情况下，Windows 正在尝试在实际c:\Python25工作目录中找到用于调用的 python 解释器。shell=False

对您的问题是：如何在不更改test1.pyand 中的代码的情况下实现目标test2.py？也许virtualenv图书馆在这种情况下可能非常有用？

非常感谢您的帮助

4

1 回答 1

1

如文档中所述：

shell 参数（默认为 False）指定是否使用 shell 作为程序来执行。

和

在 shell=True 的 Windows 上，COMSPEC 环境变量指定默认 shell。唯一需要在 Windows 上指定 shell=True 的情况是当您希望执行的命令内置到 shell 中时（例如 dir 或 copy）。您不需要 shell=True 来运行批处理文件或基于控制台的可执行文件。

因此，当您调用 时subprocess.call("test2.py")，系统会尝试将test2.py其作为可执行文件进行调用，但事实并非如此，因此它失败了。但是，您不会捕获返回值subprocess.open来检查错误情况，因此它会静默失败。当您使用 调用它时shell=True，它会使用参数 调用系统 shell test2.py，后者会依次查找.py系统上文件的默认可执行文件，然后以这种方式执行文件。

尽管如此，这里更深层次的问题是你的代码设计得很糟糕。您有正当理由通过操作系统从另一个 python 脚本分派 python 脚本的可能性非常小。与其在已有的基础上修补另一个笨拙的 hack，不如省去自己的麻烦，并重构系统，让它以更简单、更明智、更自然的集成方式做事。

于 2012-11-30T20:34:16.590 回答