The primary difference between execv and execvp is that with execv you have to provide the full path to the binary file (i.e., the program). The argv[] array is the same otherwise. For example:

#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>

int main(int argc, char * argv[]){

  //argv array for: /bin/ls -l
  char * ls_args[] = { "/bin/ls" , "-l", NULL};
  //                                  ^
  //       all argv arrays must be ___| 
  //       NULL terminated       

  //execute the program
  execv(   ls_args[0],     ls_args);
  //           ^              ^
  //           |              |
  // Name of program        argv array
  // is ls_args[0]          for ls_args


  //only get here on error
  perror("execv");
  return 2;
}

aviv@saddleback: demo $ ./execv_ls-l 
total 120
-rwxr-x--- 1 aviv scs  9890 Feb 24 14:13 exec_other
-rw-r----- 1 aviv scs   151 Feb 24 11:43 exec_other.c
-rwxr-x--- 1 aviv scs  9977 Feb 24 14:13 execv_ls-l
-rw-r----- 1 aviv scs   559 Feb 24 11:42 execv_ls-l.c
-rwxr-x--- 1 aviv scs  9979 Feb 24 14:13 execvp_ls-l
-rw-r----- 1 aviv scs   360 Feb 24 11:59 execvp_ls-l.c
-rw-r----- 1 aviv scs   559 Feb 24 11:58 execvp_ls-l.c~
-rwxr-x--- 1 aviv scs 10023 Feb 24 14:13 first_fork
-rw-r----- 1 aviv scs   532 Feb 23 08:06 first_fork.c
-rwxr-x--- 1 aviv scs 10345 Feb 24 14:13 fork_exec_wait
-rw-r----- 1 aviv scs  1158 Feb 23 08:06 fork_exec_wait.c
-rwxr-x--- 1 aviv scs 10278 Feb 24 14:13 get_exitstatus
-rw-r----- 1 aviv scs  1379 Feb 23 08:06 get_exitstatus.c
-rwxr-x--- 1 aviv scs  9985 Feb 24 14:13 get_pid_ppid
-rw-r----- 1 aviv scs   294 Feb 23 08:06 get_pid_ppid.c
-rw-r----- 1 aviv scs    99 Feb 23 08:06 Makefile

With execvp, you do not need to specify the full path because execvp will search the local environment variable PATH for the executable. Recall, that this is how the shell command which works:

aviv@saddleback: demo $ which ls
/bin/ls

which will find the name of the command along the path:

aviv@saddleback: demo $ echo $PATH
/home/scs/aviv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

In the case for ls this occurs in /bin. Using execvp will perform this look up for you, and so can simplify the code some:

aviv@saddleback: demo $ cat execvp_ls-l.c
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>

int main(int argc, char * argv[]){

  //argv array for: ls -l
  char * ls_args[] = { "ls" , "-l", NULL};
  //                    ^ 
  //  use the name ls
  //  rather than the
  //  path to /bin/ls
  execvp(   ls_args[0],     ls_args);


  //only get here on error
  perror("execv");
  return 2;
}

aviv@saddleback: demo $ ./execvp_ls-l 
total 120
-rwxr-x--- 1 aviv scs  9890 Feb 24 14:13 exec_other
-rw-r----- 1 aviv scs   151 Feb 24 11:43 exec_other.c
-rwxr-x--- 1 aviv scs  9977 Feb 24 14:13 execv_ls-l
-rw-r----- 1 aviv scs   559 Feb 24 11:42 execv_ls-l.c
-rwxr-x--- 1 aviv scs  9979 Feb 24 14:13 execvp_ls-l
-rw-r----- 1 aviv scs   360 Feb 24 11:59 execvp_ls-l.c
-rw-r----- 1 aviv scs   559 Feb 24 11:58 execvp_ls-l.c~
-rwxr-x--- 1 aviv scs 10023 Feb 24 14:13 first_fork
-rw-r----- 1 aviv scs   532 Feb 23 08:06 first_fork.c
-rwxr-x--- 1 aviv scs 10345 Feb 24 14:13 fork_exec_wait
-rw-r----- 1 aviv scs  1158 Feb 23 08:06 fork_exec_wait.c
-rwxr-x--- 1 aviv scs 10278 Feb 24 14:13 get_exitstatus
-rw-r----- 1 aviv scs  1379 Feb 23 08:06 get_exitstatus.c
-rwxr-x--- 1 aviv scs  9985 Feb 24 14:13 get_pid_ppid
-rw-r----- 1 aviv scs   294 Feb 23 08:06 get_pid_ppid.c
-rw-r----- 1 aviv scs    99 Feb 23 08:06 Makefile

You might be wondering: why use execv at all when you have execvp? There are a few good reasons, but the most relevant is for security. The PATH can be changed by the user to circumvent which programs are found during lookup. For example, what happens if there was another program called ls along the path, but this time that program removed the whole file system. execvp would call the wrong ls … and boom. execv forces issues and ensures that the whole path to the executable is provided.

The last item to consider in the exec calls is the argv array. This is the same as the argv array argument to main; essentially, when you call exec you are calling that programs main function.

Just like in main, the argv array must be NULL terminated. So when we do this:

char * ls_args[] = { "ls" , "-l", NULL};

We are setting up the argv array like so:

            .-----.
ls_args ->  |  .--+--> "/bin/ls"
            |-----|
            |  .--+--> "-l"
            |-----|
            |  .--+--> NULL
            '-----'

Because the argv array for exec is the same as main, it becomes quite trivially to write a program that just executes another program as specified on the command line. For example:

aviv@saddleback: demo $ ./exec_other ls -l
total 120
-rwxr-x--- 1 aviv scs  9890 Feb 24 14:13 exec_other
-rw-r----- 1 aviv scs   151 Feb 24 11:43 exec_other.c
-rwxr-x--- 1 aviv scs  9977 Feb 24 14:13 execv_ls-l
-rw-r----- 1 aviv scs   559 Feb 24 11:42 execv_ls-l.c
-rwxr-x--- 1 aviv scs  9979 Feb 24 14:13 execvp_ls-l
-rw-r----- 1 aviv scs   360 Feb 24 11:59 execvp_ls-l.c
-rw-r----- 1 aviv scs   559 Feb 24 11:58 execvp_ls-l.c~
-rwxr-x--- 1 aviv scs 10023 Feb 24 14:13 first_fork
-rw-r----- 1 aviv scs   532 Feb 23 08:06 first_fork.c
-rwxr-x--- 1 aviv scs 10345 Feb 24 14:13 fork_exec_wait
-rw-r----- 1 aviv scs  1158 Feb 23 08:06 fork_exec_wait.c
-rwxr-x--- 1 aviv scs 10278 Feb 24 14:13 get_exitstatus
-rw-r----- 1 aviv scs  1379 Feb 23 08:06 get_exitstatus.c
-rwxr-x--- 1 aviv scs  9985 Feb 24 14:13 get_pid_ppid
-rw-r----- 1 aviv scs   294 Feb 23 08:06 get_pid_ppid.c
-rw-r----- 1 aviv scs    99 Feb 23 08:06 Makefile
aviv@saddleback: demo $ ./exec_other cat exec_oth
exec_other    exec_other.c  
aviv@saddleback: demo $ ./exec_other cat exec_other.c 
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>

int main(int argce, char * argv[]){

  execvp( (argv+1)[0], argv+1);
  perror("execvp");
}

As you can see in the program (which used cat to output itself!) we are using pointer manipulation to set up the argv array. At the start, the argv is like:

         .-----.
argv ->  |  .--+--> "./exec_other"
         |-----|
         |  .--+--> "ls"
         |-----|
         |  .--+--> "-l"
         |-----|
         |  .--+--> NULL
         '-----'

After point manipulation:

           .-----.
           |  .--+--> "./exec_other"
           |-----|
argv+1 ->  |  .--+--> "ls"
           |-----|
           |  .--+--> "-l"
           |-----|
           |  .--+--> NULL
           '-----'

Which is a valid argv array for executing ls.

With the exception of two O.S. processes, the kernel and init process, all process are spawned from another process. The procedure of creating a new process is called forking: An exact copy of the process, memory values and open resources, is produced. The original process that forked, is called the parent, while the newly created, duplicate process is called the child. Let's look at an example of a process forking using the fork() system call:

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main(){

  pid_t c_pid;


  c_pid = fork(); //duplicate                                                                                                                                                
  if( c_pid == 0 ){
    //child: The return of fork() is zero                                                                                                                                    
    printf("Child: I'm the child: %d\n", c_pid);

  }else if (c_pid > 0){
    //parent: The return of fork() is the process of id of the child                                                                                                         

    printf("Parent: I'm the parent: %d\n", c_pid);

  }else{
    //error: The return of fork() is negative                                                                                                                                

    perror("fork failed");
    _exit(2); //exit failure, hard                                                                                                                                           

  }

  return 0; //success                                                                                                                                                        
}

The fork() system call is unlike any other function call you've seen so far. It returns twice, once in the parent and once in child, and it returns different values in the parent and the child.

To follow the logic, you first need to realize that once fork() is called, the Operating System is creating a whole new process which is an exact copy of the original process. At this point, fork() still hasen't returned because the O.S. is context switched in, and now it must return from fork() twice, once in the child process and once in the parent, where execution in both process can continue.

Every process has a unique identifier, the process identifier or pid. This value is assigned by the operating system when the process is created and is a 2-byte number (or a short). There is a special typedef for the process identifier, pid_t, which we will use.

In the above sample code, after the call to fork(), the parent's return value from fork() is the process id of the newly created child process. The child, however, has a return value of 0. On error, fork(), returns -1. Then you should bail with _exit() because something terrible happened.

One nice way to see a visual of the parent process relationship is using the bash command pstree:

#> pstree -ah
init
  ├─NetworkManager
  │   ├─dhclient -d -4 -sf /usr/lib/NetworkManager/nm-dhcp-client.action -pf /var/run/sendsigs.omit.d/network-manager.dhclient-eth0.pid -lf...
  │   └─2*[{NetworkManager}]
  ├─accounts-daemon
  │   └─{accounts-daemon}
(...)

At the top is the init process, which is the parent of all proces. Somewhere down tree is my login shell

(...)
├─sshd -D
  │   └─sshd   
  │       └─sshd    
  │           └─bash
  │               ├─emacs get_exitstatus.c
  │               ├─emacs foursons.c
  │               ├─emacs Makefile
  │               ├─emacs get_exitstatus.c
  │               ├─emacs fork_exec_wait.c
  │               ├─emacs mail_reports.py
  │               └─pstree -ah
(...)

And you can see that the process of getting to a bash shell via ssh requires a number of forks and child process.

With fork(), the parent can learn the process id of the child, but the child doesn't know its own process id (or pid) after the fork nor does it know its parents process id. For that matter, the parent doesn't know its own process id either. There are two system calls to retrieve this information:

//retrieve the current process id
pid_t getpid(void);

//retrieve the parent's process id
pid_t getppid(void);

There is no way for a process to directly retrieve its child pid because any process may have multiple children. Instead, a process must maintain that information directly through the values returned from a fork(). Here is a sample program that prints the current process id and the parent's process id.

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main(){
  pid_t pid, ppid;

  //get the process'es pid
  pid = getpid();

  //get the parrent of this process'es pid
  ppid = getppid();


  printf("My pid is: %d\n",pid);
  printf("My parent's pid is %d\n", ppid);

  return 0;
}

If we run this program a bunch of times, we will see output like this:

#> ./get_pid_ppid 
My pid is: 14307
My parent's pid is 13790

#> ./get_pid_ppid 
My pid is: 14308
My parent's pid is 13790

#> ./get_pid_ppid 
My pid is: 14309
My parent's pid is 13790

Every time the program runs, it has a different process id (or pid). Every process must have a unique pid, and the O.S. applies a policy for reusing process id's as processes terminate. But, the parent's pid is the same. If you think for a second, this makes sense: What's the parent of the program? The shell! We can see this by echo'ing $$, which is special bash variable that stores the pid of the shell:

#> echo $$
13790

Whenever you execute a program on the shell, what's really going on is the shell is forking, and the new child is exec'ing the new program. One thing to consider, though, is that when a process forks, the parent and the child continue executing in parallel: Why doesn't the shell come back immediately and ask the user to enter a new command? The shell instead waits for the child to finish process before prompting again, and there is a system call called wait() to just do that.

To learn about the exit status of a program we can use the macros from sys/wait.h which check the termination status and return the exit status. From the main page:

WIFEXITED(status)
       returns true if the child terminated normally, that is, 
       by calling exit(3) or _exit(2), or by returning from main().

WEXITSTATUS(status)
       returns  the  exit  status of the child.  This consists of the least significant 
       8 bits of the status argument that the child specified in a call to exit(3) or _exit(2) or as the
       argument for a return statement in main().  
       This macro should only be employed if WIFEXITED returned true.

There are other checks of the termination status, and refer to the manual page for more detail. Below is some example code for checking the exit status of forked child. You can see that the child delays its exit by 2 seconds with a call to sleep.

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

#include <sys/types.h>
#include <sys/wait.h>

int main(){

  pid_t c_pid, pid;
  int status;

  c_pid = fork(); //duplicate

  if( c_pid == 0 ){
    //child
    pid = getpid();

    printf("Child: %d: I'm the child\n", pid, c_pid);
    printf("Child: sleeping for 2-seconds, then exiting with status 12\n");

    //sleep for 2 seconds
    sleep(2);

    //exit with statys 12
    exit(12);

  }else if (c_pid > 0){
    //parent

    //waiting for child to terminate
    pid = wait(&status);

    if ( WIFEXITED(status) ){
      printf("Parent: Child exited with status: %d\n", WEXITSTATUS(status));
    }

  }else{
    //error: The return of fork() is negative
    perror("fork failed");
    _exit(2); //exit failure, hard
  }

  return 0; //success                                                                                                                                                        
}