Bash – Is the command in a process substitution invoked in a subshell

bashprocess-substitutionsubshell

From the bash manual

Process substitution is supported on systems that support named pipes
(fifos) or the /dev/fd method of naming open files. It takes the form
of
<(list)
or
>(list)
The process
list is run with its input or output connected to a fifo or some file
in /dev/fd. The name of this file is passed as an argument to the
current command as the result of the expansion.

Is the command list in a process substitution <(list) or >(list) invoked in a subshell, similarly to a command substitution, commands grouped with parentheses, and
asynchronous commands? Similar as the bash manual says

Command substitution, commands grouped with parentheses, and
asynchronous commands are invoked in a subshell environment that
is a duplicate of the shell environment, except that traps caught by
the shell are reset to the values that the shell inherited from its
parent at invocation.

The answer might be yes, because
- process substitution looks similar to command substitution,
- some source says that
  
  the command inside it is run in the background.
and the above second quote from the bash manual says that both command
substitution and backgrounded commands are invoked in subshells.
The answer might be no, because
- In the bash manual, I didn't see that a process substitution is mentioned in the above second quote from the bash manual,
- and some source says that process substitution
  
  is especially important for bypassing subshells caused by pipelines
  
  although I am not sure if "bypassing subshells" means not being invoked in a subshell.

Best Answer

Running the current shell under strace(1) and then executing e.g. <(command) gives:

clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fa6713d59d0) = 13305

From a purely definitional standpoint, since clone(2) is defined as

create a child process

and a subshell as

Running a shell script launches a new process, a subshell.

one could say that yes - running process substitution is invoked as a subshell.

Related Solutions

Bash – Rule for Invoking Subshell

The parentheses always start a subshell. What's happening is that bash detects that sleep 5 is the last command executed by that subshell, so it calls exec instead of fork+exec. The sleep command replaces the subshell in the same process.

In other words, the base case is:

( … ) create a subshell. The original process calls fork and wait. In the subprocess, which is a subshell:
1. sleep is an external command which requires a subprocess of the subprocess. The subshell calls fork and wait. In the subsubprocess:
  1. The subsubprocess executes the external command → exec.
  2. Eventually the command terminates → exit.
2. wait completes in the subshell.
wait completes in the original process.

The optimization is:

( … ) create a subshell. The original process calls fork and wait. In the subprocess, which is a subshell until it calls exec:
1. sleep is an external command, and it's the last thing this process needs to do.
2. The subprocess executes the external command → exec.
3. Eventually the command terminates → exit.
wait completes in the original process.

When you add something else after the call the sleep, the subshell needs to be kept around, so this optimization can't happen.

When you add something else before the call to sleep, the optimization could be made (and ksh does it), but bash doesn't do it (it's very conservative with this optimization).

Bash – are non-environment variables passed to the subshell invoqued by command substitution

No, the subshell was created first.

A shell execution environment contains shell parameters set by variable assignments and environment variables. A subshell environment was created by duplicating the shell environment, so it contains all the variables of the current shell environment.

See the example:

$ b=1
$ c=$(b=2; echo "$b")
$ echo "$c"
2

The output is 2 instead of 1.

A subshell environment created by command substitution is different with a shell environment created by calling the shell executable.

When you call the shell as:

$ bash -c :

the the current shell used execve() to create new shell process, something like:

execve("/bin/bash", ["bash", "-c", ":"], [/* 64 vars */]) = 0

the last argument passed to execve contains all the environment variables.

That's why you need to export the variables to push it to the environment variables, which will be included in subsequently executed commands:

$ a=; export a
$ strace -e execve bash -c :
execve("/bin/bash", ["bash", "-c", ":"], [/* 65 vars */]) = 0
+++ exited with 0 +++

Notice the environment variables change from 64 to 65. And variables which are not exported will not be passed to new shell environment:

$ a=; b=; export a
$ strace -e execve bash -c :
execve("/bin/bash", ["bash", "-c", ":"], [/* 65 vars */]) = 0
+++ exited with 0 +++

Notice the environment variables are still 65.

In command substitution, the shell used fork() to create new shell process, which just copied the current shell environment - which contains both variables set and environment variables.

Best Answer

Related Solutions

Bash – Rule for Invoking Subshell

Bash – are non-environment variables passed to the subshell invoqued by command substitution

Related Question