Is a child shell's life over shortly after it's created? I.e., do its assets get replaced by the process that is going to be run in it? Say we've run
grep -r "something"
in bash, so our shell(bash) creates a sub-process, which is not "grep" initially, it's just a fork of bash itself at first, but then since we ultimately want the "grep" to be run, the assets of the child shell will "rapidly" get replaced by the grep's process. (In a diagram: Shell ---> "Child Shell"(short life?) ---> Process)Do all shell commands create child shells? E.g., does running a command as simple as "ls -l" also create a child process for a tiny bit of time? Because the same reason(as explained in 1) applies here again, "ls" is a program in itself, and when it's run, we don't want its process to replace our own shell's process.
If the answer to 2 is "Yes", does that mean running a shell script which contains many shell commands, will result in creation of "many" child shells and processes?
1 Answers
It’s important to distinguish processes and what’s running inside them (and your question suggests you’re aware of this distinction). Whenever a given program, running in a process, wants to run another program, it has two options: it can ask the operating system to replace it in the current process with the new program (the exec
family of functions), or it can ask the operating system to create a new process (the fork
function and then in that process ask the operating system to replace it in the new process with the new program.
When you run
grep
from a shell, the shell typically wants to regain control after, so it forks, runsgrep
in the fork, and waits for the forked process to finish. So yes, the shell in the fork is short-lived, but “creating” the “assets” of the shell in the fork didn’t cost much at all on most current operating systems (thanks to copy-on-write mechanisms).The same applies for an
ls -l
from an interactive shell. However, in some circumstances the shell will replace itself instead of forking; see Why bash does not spawn a subshell for simple commands? for details.Running a shell script will create one process for the shell running the script, and one process for each external command in the shell, and possibly sub-shells for certain shell constructs.
Creating processes is cheap, but exec
ing less so; that’s part of the reason why people often care about limiting the number of processes being used. Two other reasons, which are perhaps more important, are that starting a program involves the cost of that’s program’s startup, and often involves repeating parts of an overall process (compare find ... -exec grep
and grep -r
on systems which have the latter, or multiple invocations of grep
, sed
etc. compared to a single sed
or awk
). Once you start hitting speed issues in shell scripts because you’re relying on external commands too much, that’s often a clue that it’s time to use a more capable programming environment which will allow more data processing without involving other programs.

- 434,908
-
Thanks this completely answers my question. Can you please also give an example for the last sentence in your answer(a more capable programming environment which...). – aderchox Sep 10 '20 at 08:02
-
1
fork
used to be expensive, and it keeps that reputation even though it’s been cheap for a long time (since copy-on-write became possible, at various times on various architectures and operating systems). – Stephen Kitt Sep 10 '20 at 07:52