命令替换何时会比单独的相同命令产生更多的子 shell？

昨天有人建议我在 bash 中使用命令替换会导致生成不必要的子 shell。该建议具体针对这个用例 https://stackoverflow.com/q/21317997/313192:

# Extra subshell spawned
foo=$(command; echo $?)

# No extra subshell
command
foo=$?

据我所知，这对于这个用例来说似乎是正确的。然而，试图验证这一点的快速搜索会导致大量令人困惑和矛盾的建议。流行的观点似乎是，所有命令替换的使用都会产生一个子 shell。例如：

命令替换扩展到命令的输出。这些命令在子 shell 中执行，它们的标准输出数据是替换语法扩展到的内容。 (source http://wiki.bash-hackers.org/syntax/expansion/cmdsubst)

这看起来很简单，除非您继续挖掘，在这种情况下，您将开始找到对建议的引用，但事实并非如此。

命令替换不一定调用子shell，并且在大多数情况下不会。它唯一保证的是乱序求值：它只是先求值替换中的表达式，然后使用替换的结果求值周围的语句。 (source https://github.com/grncdr/js-shell-parse/issues/1)

这似乎很有道理，但事实果真如此吗？这个答案 https://stackoverflow.com/a/9109654/313192一个与子外壳相关的问题让我注意到man bash有一点需要注意：

管道中的每个命令都作为单独的进程执行（即在子 shell 中）。

这让我想到了主要问题。到底是什么会导致命令替换产生一个无论如何也不会产生的子 shell 来单独执行相同的命令？

请考虑以下情况并解释哪些情况会产生额外子 shell 的开销：

# Case #1
command1
var=$(command1)

# Case #2
command1 | command2
var=$(command1 | command2)

# Case #3
command1 | command 2 ; var=$?
var=$(command1 | command2 ; echo $?)

这些对中的每一对都会产生相同数量的子 shell 来执行吗？ POSIX 与 bash 实现有区别吗？是否存在其他情况，使用命令替换会生成子 shell，而单独运行同一组命令则不会？

更新和警告:

这个答案有一个麻烦的过去，因为我自信地声称事实证明不是真的。我相信它有它的价值current形式，但请帮助我消除其他不准确之处（或说服我应该将其完全删除）。

I've 大幅修改 - 并且大部分被删除 - 这个答案在@kojiro指出我的测试方法有缺陷之后（我最初使用ps寻找子进程，但这太慢而无法始终检测到它们）；下面描述一种新的测试方法。

我最初声称并非所有 bash 子 shell 都在自己的子进程中运行，但事实证明并非如此。

正如@kojiro 在他的回答中所说，someshell - 除了 bash - 有时要避免为子 shell 创建子进程，因此，一般来说在 shell 的世界中，人们不应该假设子 shell 意味着子进程。

至于OP的案例bash（假设command{n}实例是简单的命令):

# Case #1
command1         # NO subshell
var=$(command1)  # 1 subshell (command substitution)

# Case #2
command1 | command2         # 2 subshells (1 for each pipeline segment)
var=$(command1 | command2)  # 3 subshells: + 1 for command subst.

# Case #3
command1 | command2 ; var=$?         # 2 subshells (due to the pipeline)
var=$(command1 | command2 ; echo $?) # 3 subshells: + 1 for command subst.;
                                     #   note that the extra command doesn't add 
                                     #   one

看起来像使用命令替换（$(...)) 总是在 bash 中添加额外的子 shell- 就像将任何命令包含在(...).

我相信，但不确定这些结果是否正确;这是我的测试方法（OS X 10.9.1 上的 bash 3.2.51）-请告诉我这种方法是否有缺陷:

• 确保只有 2 个交互式 bash shell 正在运行：一个用于运行命令，另一个用于监视。
• 在第二个 shell 中我监控了fork()第 1 次调用sudo dtruss -t fork -f -p {pidOfShell1} (the -f还需要追踪fork()调用“传递”，即包括那些由子 shell 本身创建的）。

• 只使用内置的:（无操作）在测试命令中（以避免用额外的内容混淆图片）fork()调用外部可执行文件）；具体来说：

  • :
  • $(:)
  • : | :
  • $(: | :)
  • : | :; :
  • $(: | :; :)

• 只统计了那些dtruss包含非零 PID 的输出行（因为每个子进程还报告fork()创建它的调用，但 PID 为 0）。

• 从结果数中减去 1，因为即使只是从交互式 shell 中运行内置函数显然也至少涉及 1fork().
• 最后，假设结果计数代表创建的子 shell 的数量。

以下是我仍然认为我原来的帖子中正确的内容：当 bash 创建子 shell 时。

bash 在以下情况下创建子 shell：

• for an expression surrounded by parentheses ( (...) )
  • except直接在里面[[ ... ]]，其中括号仅用于逻辑分组。

• for every segment of a pipeline (|), including the first one
  • 注意every涉及的子shell是一个克隆original外壳方面content（就进程而言，子 shell 可以从其他子 shell 中派生出来（before命令被执行））。
    因此，早期管道段中子 shell 的修改不会影响后面的管道段。
    （根据设计，管道中的命令会启动同时地- 排序仅通过其连接的 stdin/stdout 管道进行。）
  • bash 4.2+有外壳选项lastpipe（默认为关闭），这会导致last管道段不能在子 shell 中运行。

• 对于命令替换（$(...))

• 对于过程替换（<(...))

  • 通常会创建2子壳；如果是简单的命令, @konsolebox想出了一种技术 https://stackoverflow.com/a/24655246/45375只创造1: 在简单命令前面加上exec (<(exec ...)).

• 后台执行（&)

组合这些结构将产生多个子 shell。