根据某些需要，我被迫纠正os.environ['PATH']以便能够运行dir\to\fake\python.cmd脚本，该脚本在执行之前会向原始脚本添加一些额外的参数。
我还有两个python脚本：
test1.py：
# ...
p = subprocess.call("test2.py") # shell=True works fine
# ...
test2.py：
# ...
print "Hello from test2.py"
# ...
当我运行python test1.py我的“假”python.cmd做它的东西时，引用c:\Python25中的原始python并使用我的额外参数运行test1.py。但是，遗憾的是，test2.py，脚本永远不会被调用。如果我将shell=True作为subprocess.call参数 - 一切都很好，test2.py被调用。
我知道，当c:\Python25默认为shell=False时，Windows正试图找到用于真实test1.py工作目录中的调用的python解释器。
问题是：如何在不更改test2.py和virtualenv中的代码的情况下实现目标？在这种情况下，{{1}}库可能非常有用吗？
非常感谢您的帮助
答案 0 :(得分：1)
如the docs中所述：
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调用它时，它会使用参数test2.py调用系统shell，该参数会查找系统上.py文件的默认可执行文件，然后以这种方式执行文件
尽管如此，这里更深层次的问题是您的代码设计非常糟糕。您有合理理由通过操作系统从另一个python脚本发送python脚本的可能性非常小。而不是修补你已经拥有的另一个kladgy hack，在未来保存自己的头痛并重构系统，以便它以更容易，更明智，更自然的方式完成事情。