Когда подстановка команд порождает больше подоболочек, чем одни и те же команды по отдельности?

Обновите и предупредите:

У этого ответа было проблемное прошлое, поскольку я уверенно утверждал то, что оказалось неправдой. Я считаю, что в своем текущем виде оно представляет ценность, но, пожалуйста, помогите мне устранить другие неточности (или убедите меня, что его следует вообще удалить).

Я существенно пересмотрел - и в основном выпотрошил - этот ответ после того, как @kojiro указал, что мои методы тестирования ошибочны (первоначально я использовал ps для поиска дочерних процессов, но это слишком медленно, чтобы всегда их обнаруживать) ; новый метод тестирования описан ниже.

Первоначально я утверждал, что не все подоболочки bash работают в своих собственных дочерних процессах, но это оказалось не так.

Как утверждает @kojiro в своем ответе, некоторые оболочки, кроме bash, иногда ДЕЙСТВИТЕЛЬНО избегают создания дочерних процессов для подоболочек, поэтому, вообще говоря, в мире оболочек один не следует предполагать, что подоболочка подразумевает дочерний процесс.

Что касается случаев 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, как и включение любой команды в (...).

Верю, но не уверен, что эти результаты верны; вот как я тестировал (bash 3.2.51 на OS X 10.9.1) - пожалуйста, сообщите мне, если этот подход ошибочен:

• Убедился, что запущены только 2 интерактивные оболочки bash: одна для запуска команд, другая для мониторинга.
• Во 2-й оболочке я отслеживал вызовы fork() в 1-й с помощью sudo dtruss -t fork -f -p {pidOfShell1} (-f необходим для "транзитивной" трассировки вызовов fork(), т.е. для включения тех, которые созданы самими подоболочками).

• Использовались только встроенные : (no-op) в тестовых командах (чтобы не запутать картинку дополнительными fork() вызовами внешних исполняемых файлов); конкретно:

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

• Учитывались только те выходные строки dtruss, которые содержали ненулевой PID (поскольку каждый дочерний процесс также сообщает о вызове fork(), который его создал, но с PID 0).

• Из полученного числа вычтено 1, так как запуск даже встроенной функции из интерактивной оболочки, по-видимому, требует как минимум 1 fork().
• Наконец, предположим, что результирующий счетчик представляет собой количество созданных подоболочек.

Ниже приведено то, что я все еще считаю правильным из моего исходного сообщения: когда bash создает подоболочки.

bash создает подоболочки в следующих случаях:

• for an expression surrounded by parentheses ( (...) )
  • except directly inside [[ ... ]], where parentheses are only used for logical grouping.

• for every segment of a pipeline (|), including the first one
  • Note that every subshell involved is a clone of the original shell in terms of content (process-wise, subshells can be forked from other subshells (before commands are executed)).
    Thus, modifications of subshells in earlier pipeline segments do not affect later ones.
    (By design, commands in a pipeline are launched simultaneously - sequencing only happens through their connected stdin/stdout pipes.)
  • bash 4.2+ имеет параметр оболочки lastpipe (по умолчанию ВЫКЛ), из-за которого последний сегмент конвейера НЕ запускается в подоболочке.

• для подстановки команд ($(...))

• для замены процесса (<(...))

  • typically creates 2 subshells; in the case of a simple command, @konsolebox came up with a technique to only create 1: prepend the simple command with exec (<(exec ...)).

• фоновое выполнение (&)

Объединение этих конструкций приведет к более чем одной подоболочке.

В Bash подоболочка всегда выполняется в новом пространстве процесса. Вы можете довольно просто проверить это в Bash 4, который имеет переменные окружения $BASHPID и $$:

• $$ Заменяется идентификатором процесса оболочки. В подоболочке () он расширяется до идентификатора процесса текущей оболочки, а не подоболочки.
• BASHPID Заменяется идентификатором текущего процесса bash. Это отличается от $$ при определенных обстоятельствах, таких как подоболочки, которые не требуют повторной инициализации bash.

на практике:

$ type echo
echo is a shell builtin
$ echo $$-$BASHPID
4671-4671
$ ( echo $$-$BASHPID )
4671-4929
$ echo $( echo $$-$BASHPID )
4671-4930
$ echo $$-$BASHPID | { read; echo $REPLY:$$-$BASHPID; }
4671-5086:4671-5087
$ var=$(echo $$-$BASHPID ); echo $var
4671-5006

Единственным случаем, когда оболочка может исключить дополнительную подоболочку, является когда вы подключаетесь к явной подоболочке:

$ echo $$-$BASHPID | ( read; echo $REPLY:$$-$BASHPID; )
4671-5118:4671-5119

Здесь подоболочка, подразумеваемая каналом, применяется явно, но не дублируется.

Это отличается от некоторых других оболочек, которые очень стараются избежать fork-ing. Поэтому, хотя я считаю, что аргумент, сделанный в js-shell-parse, вводит в заблуждение, это правда, что не все оболочки всегда fork для всех подоболочек.