Learning Question
How does a Unix/Linux system start a new program as a running process?
Unix/Linux process creation is often explained through two separate ideas: creating a process and replacing that process’s program image.
The common model is fork followed by exec.
The first mental model is:
forkcreates a new process.execreplaces the current process image with a different program.
Creating a Child Process
On Unix/Linux, fork creates a child process from the calling process.
After fork, there are two processes:
- the parent process
- the child process
They continue from the same point in the code, but fork returns different values in each process so the program can distinguish parent behavior from child behavior.
The child is not a new thread.
It is a separate process with its own process ID and process state.
Copying Without Copying Everything Immediately
Conceptually, the child starts as a copy of the parent process.
In practice, modern systems avoid immediately copying all memory.
Copy-on-write lets parent and child share physical pages until one of them modifies a page.
This makes fork efficient enough for common process-creation patterns.
The conceptual boundary remains:
After
fork, parent and child are separate processes, even if the OS temporarily shares unchanged memory pages internally.
Program Replacement With exec
exec does not create a new process.
It replaces the current process image with a new program image.
After a successful exec, the old code is gone from that process.
The process keeps its identity in important ways, such as its process ID, but its address space and executable program content are replaced.
This is why the phrase “call exec and return to the old program” is usually wrong.
If exec succeeds, it does not return to the old program flow.
Why Shells Use fork and exec
When a shell runs a command, it usually needs to keep itself alive while starting another program.
The shell can:
forka child process- configure the child process, such as redirection or environment
- call
execin the child to replace it with the target program - wait for the child or continue, depending on foreground/background behavior
The shell process remains the shell.
The child process becomes the command.
This model explains why command execution is process behavior, not direct function invocation inside the shell.
Environment, Arguments, and Descriptors
When a new program starts through exec, it receives startup information such as arguments and environment variables.
Open file descriptors may also remain open across exec unless marked close-on-exec.
This detail is central to redirection and pipelines.
A shell can prepare descriptors first, then execute a program.
The new program simply reads from standard input or writes to standard output.
It does not need to know how the shell connected those descriptors.
Process Trees
Processes form relationships.
A process can create children.
Those children can create more children.
Tools may show this as a process tree.
The tree matters for job control, waiting, signal delivery patterns, and understanding which program started which other program.
It is also why a child process’s exit status can be observed by its parent.
Core Mental Model
Unix/Linux separates process creation from program replacement.
fork gives the system another process.
exec gives that process a new program image.
When reasoning about command execution, ask:
Which process is being created, which process image is being replaced, and which descriptors or environment values survive into the new program?
Final Summary
Unix/Linux commonly starts programs by creating a child process and then replacing the child process image with the target executable.
This fork/exec split explains shells, redirection, pipelines, process identity, inherited descriptors, and the difference between creating a process and loading a different program into it.