Sub-Shell vs Child-Shell – Is a Sub-Shell the Same Thing as a Child-Shell?

bashposixprocessshellsubshell

There are this two names: a subshell and a child-shell.

Yes, a child process will be started by any of this:

sh -c 'echo "Hello"'
( echo "hello" )
echo "$(echo "hello")
echo "hello" | cat

Are all equivalent and share the same name? Do all share the same properties?

POSIX has this definition:

A shell execution environment consists of ….

But the last paragraph of above link has this:

A subshell environment shall be created as a duplicate of the shell environment, except that signal traps that are not being ignored shall be set to the default action.

And specially:

Command substitution, commands that are grouped with parentheses, and asynchronous lists shall be executed in a subshell environment. Additionally, each command of a multi-command pipeline is in a subshell environment; ….

The sh -c 'echo "Hello"' is not included there, should that be called a subshell also?

Best Answer

A subshell duplicates the existing shell. It has the same variables¹, the same functions, the same options, etc. Under the hood, a subshell is created with the fork system call²; the child process goes on to do what is expected of it while the parent waits (e.g., $(…)) or goes on with its life (e.g., … &) or otherwise does what is expected of it (e.g., … | …).

sh -c … does not create a subshell. It launches another program. That program happens to be a shell, but that's just a coincidence. The program may even be a different shell (e.g., if you run sh -c … from bash, and sh is dash), i.e., a completely different program that just happens to have significant similarities in its behavior. Under the hood, launching an external command (sh or any other) calls the fork system call and then the execve system call to replace the shell program in the subprocess by another program (here sh).

¹ _{Including $$, but excluding some shell-specific variables such as bash and mksh's BASHPID.}
² _{At least, that's the traditional and usual implementation. Shells can optimize the fork away if they can mimic the behavior otherwise.}

Relevant man pages: fork(2), execve(2).

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).

Shell – How to trace system calls being invoked after typing command

As mentioned in one of the answers to your previous question, the exec family call happens after the child process is created, so if you want it to appear in the strace output then you have to make it also follow children of the shell process you are tracing.

You can do this by adding either the -f or -ff options, here are the relevant man page snippets:

 -f  Trace child processes as they are created by currently traced processes as a
     result of the fork(2) system call.

-ff  If the -o filename option is in effect, each processes trace is written to
     filename.pid where pid is the numeric process id of each process.  This is
     incompatible with -c, since no per-process counts are kept.

To trace the relevant calls involved in running a command in bash you can do:

strace -f -e trace=process bash -c 'ls; :'

The -e trace=process specifically traces all calls involved in process management. Also the second no-op command (:) is needed as if you run bash with only a single command, it is smart enough to just do an execve without forking since it knows it doesn't need to do anything else.

Best Answer

Related Solutions

Bash – Rule for Invoking Subshell

Shell – How to trace system calls being invoked after typing command

Related Question