为什么 shell=True 的 subprocess.Popen() 在 Linux 和 Windows 上的工作方式不同？

Question

当使用 subprocess.Popen(args, shell=True) 运行“gcc --version”（仅作为示例）时，在 Windows 上我们得到：

>>> from subprocess import Popen
>>> Popen(['gcc', '--version'], shell=True)
gcc (GCC) 3.4.5 (mingw-vista special r3) ...

所以它很好按我的预期打印出版本。 但在 Linux 上我们得到这样的结果：

>>> from subprocess import Popen
>>> Popen(['gcc', '--version'], shell=True)
gcc: no input files

因为 gcc 还没有收到 --version 选项。

文档没有具体指定 Windows 下的 args 应该发生什么，但它确实说，在 Unix 上，“如果 args 是一个序列，则第一项指定命令字符串，任何其他项将被视为额外的 shell 参数。” 恕我直言，Windows 方式更好，因为它允许您将 Popen(arglist) 调用视为与 Popen(arglist, shell=True) 相同的方式代码>个。

为什么 Windows 和 Linux 之间存在差异？

Answer 1

实际上在 Windows 上，当 shell=True 时，它确实使用 cmd.exe - 它在前面加上 cmd.exe /c （它实际上查找 < code>COMSPEC 环境变量，但默认为 cmd.exe（如果不存在））到 shell 参数。 （在 Windows 95/98 上，它使用中间 w9xpopen 程序来实际启动该命令）。

因此，奇怪的实现实际上是 UNIX 实现，它执行以下操作（其中每个空格分隔不同的参数）：

/bin/sh -c gcc --version

看起来正确的实现（至少在 Linux 上）是：

/bin/sh -c "gcc --version" gcc --version

因为这会设置从引用的参数中获取命令字符串，并成功传递其他参数。

来自 sh 手册页中 -c 的部分：

从 command_string 操作数而不是从标准输入读取命令。 特殊参数 0 将从 command_name 操作数设置，位置参数（$1、$2 等）从其余参数操作数设置。

这个补丁似乎相当简单地实现了这一点：

--- subprocess.py.orig  2009-04-19 04:43:42.000000000 +0200
+++ subprocess.py       2009-08-10 13:08:48.000000000 +0200
@@ -990,7 +990,7 @@
                 args = list(args)

             if shell:
-                args = ["/bin/sh", "-c"] + args
+                args = ["/bin/sh", "-c"] + [" ".join(args)] + args

             if executable is None:
                 executable = args[0]

Answer 2

来自 subprocess.py 源：

在 UNIX 上，shell=True：如果 args 是字符串，则它指定
通过 shell 执行的命令字符串。 如果 args 是一个序列，
第一项指定命令字符串，以及任何其他项目
将被视为额外的 shell 参数。

在 Windows 上：Popen 类使用 CreateProcess() 来执行子进程
程序，对字符串进行操作。 如果 args 是一个序列，它将是
使用 list2cmdline 方法转换为字符串。 请注意
并非所有 MS Windows 应用程序都以相同的方式解释命令行
方式：list2cmdline 是为使用相同的应用程序而设计的
规则作为 MS C 运行时。

这并没有回答为什么，只是澄清了您正在看到预期的行为。

“原因”可能是在类 UNIX 系统上，命令参数实际上以字符串数组的形式传递给应用程序（使用 exec* 调用系列）。 换句话说，调用进程决定每个命令行参数的内容。 然而，当您告诉它使用 shell 时，调用进程实际上只有机会将单个命令行参数传递给 shell 来执行：您想要执行的整个命令行、可执行文件名称和参数，作为单个字符串。

但在 Windows 上，整个命令行（根据上述文档）作为单个字符串传递给子进程。 如果您查看 CreateProcess API 文档，您会注意到它期望所有命令行参数连接在一起形成一个大字符串（因此调用 list2cmdline）。

另外，事实上，在类 UNIX 系统上，实际上有一个 shell 可以做有用的事情，所以我怀疑造成差异的另一个原因是在 Windows 上，shell=True 不执行任何操作，这就是为什么它按照您所看到的方式工作。 使两个系统表现相同的唯一方法是在 Windows 上当 shell=True 时简单地删除所有命令行参数。

Answer 3

shell=True 的 UNIX 行为的原因与引用有关。 当我们编写shell命令时，它会被空格分割，因此我们必须引用一些参数：

cp "My File" "New Location"

当我们的参数包含引号时，这会导致问题，这需要转义：

grep -r "\"hello\"" .

有时我们可以得到可怕的情况，其中 \ 也必须转义！

当然，真正的问题是我们尝试使用一个字符串来指定多个字符串。 当调用系统命令时，大多数编程语言通过允许我们首先发送多个字符串来避免这种情况，因此：

Popen(['cp', 'My File', 'New Location'])
Popen(['grep', '-r', '"hello"'])

有时运行“原始”shell 命令可能会很好； 例如，如果我们从 shell 脚本或网站复制粘贴某些内容，并且我们不想手动转换所有可怕的转义。 这就是 shell=True 选项存在的原因：

Popen(['cp "My File" "New Location"'], shell=True)
Popen(['grep -r "\"hello\"" .'], shell=True)

我不熟悉 Windows，所以我不知道它的行为方式如何或为何不同。