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.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…