why the exec() family of functions doesn’t execute the code after exec()?

Correct. If the exec works, the perror will not be called, simply because the call to perror no longer exists.

I find it’s sometimes easier when educating newcomers to these concepts, to think of the UNIX execution model as being comprised of processes, programs and program instances.

Programs are executable files such as /bin/ls or /sbin/fdisk (note that this doesn’t include things like bash or Python scripts since, in that case, the actual executable would be the bash or python interpreter, not the script).

Program instances are programs that have been loaded into memory and are basically running. While there is only one program like /bin/ls, there may be multiple instances of it running at any given time if, for example, both you and I run it concurrently.

That “loaded into memory” phrase is where processes come into the picture. Processes are just “containers” in which instances of programs can run.

So, when you fork a process, you end up with two distinct processes but they’re still each running distinct instances of the same program. The fork call is often referred to as one which one process calls but two processes return from.

Likewise, exec will not have an effect on the process itself but it will discard the current program instance in that process and start a new instance of the requested program.

This discard in a successful exec call is what dictates that the code following it (perror in this case) will not be called.

Leave a Comment