Three Questions on Child Shells: Lifespan and Creation

Question

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?

There seems to be an overriding impression that fork is a bad (slow) thing, but I've always had the impression that it is a fairly light weight process, simply copying and create a new process header, memory, file descriptors are all the same at that point? — X Tian, Sep 10 '20 at 07:33
@XTian there’s some historical baggage there; 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

score 1 · Accepted Answer · answered Sep 10 '20 at 07:50

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, runs grep 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 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 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.

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

Three Questions on Child Shells: Lifespan and Creation

1 Answers1