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?
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
grepfrom a shell, the shell typically wants to regain control after, so it forks, runs
grepin 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 -lfrom 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
execing 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
sed etc. compared to a single
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.