exec
/ exec, 'EX-eck' /
Picture an actor who, without leaving the stage or changing their name in the program, completely changes character: new lines, new costume, new role, same body. The exec system call does this to a process: it keeps the same process (same PID) but replaces what it is running, throwing away the current program and loading a brand-new program in its place to run from the beginning.
When a process calls a member of the exec family (such as execve), the OS discards the process's current address space, its text, data, heap, and stack, and loads the requested executable file from disk into a fresh address space: the new program's code into the text segment, its data into data and BSS, a new stack, and so on. It then starts execution at the new program's entry point. Crucially the PID, and usually open files, stay the same; only the program being run is swapped out. If exec succeeds it never returns to the old code, because that code no longer exists; it only returns (with an error) if the load failed.
Exec is half of the Unix create-a-process idiom: fork makes a copy of yourself, then exec turns that copy into the program you actually want to run. This split is elegant because it lets the child, in the brief moment between fork and exec, adjust its environment (redirect input/output, change permissions) before becoming the new program. A common confusion is to expect exec to start a new, separate process; it does not. It transforms the calling process in place. To get a separate process running a new program, you fork first, then exec in the child.
A shell wanting to run 'ls' first forks; the child then calls execve on /bin/ls. The child's PID is unchanged, but its program is now ls, which runs from the start. The parent shell waits for it to finish.
Same process (same PID), brand-new program loaded in its place.
exec does not create a process; it replaces the running program inside the existing process (same PID). A successful exec never returns, because the old code is gone.