由于某些需要，我被迫更正os.environ['PATH']，以便能够运行dirtofakepython.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。
我知道，当默认情况下shell=False时，Windows正试图在真正的c:Python25工作目录中找到用于调用的python解释器。
问题是：如何在不更改test1.py和test2.py中的代码的情况下实现目标？也许virtualenv库在这种情况下可能非常有用？
非常感谢您的帮助
如文档中所述：
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脚本的可能性微乎其微。与其在现有的基础上修补另一个笨拙的黑客，不如在未来省去麻烦，重构系统，使其以更简单、更明智、更自然的集成方式做事。