§5.4–5.7Why? Motivating The API … Summary

Why would anyone design process creation as fork()‘s copy followed by exec()‘s transform, instead of one simple “run this program” call? The answer is the most-used program on any UNIX box:

5.4 Why? Motivating The API

The separation of fork() and exec() is essential to the shell shell An ordinary user program (bash, zsh, …) that reads commands and runs them via fork → exec → wait, printing a prompt in between. defined in ch. 5 — open in glossary — which is just a user program. Its whole life: show a prompt; read your command; find the executable; fork() a child; exec() the command in that child; wait() for it; prompt again.

The magic lives in the gap: the shell gets to run code after fork() but before exec() — code that alters the environment of the about-to-run program. That’s what makes features like this a one-liner:

prompt> wc p3.c > newfile.txt

Redirection redirection Pointing a process's standard input/output at a file — the shell's child closes a descriptor and opens the file before exec (UNIX assigns the lowest free fd). defined in ch. 5 — open in glossary : wc’s output lands in newfile.txt instead of the screen. Step through how the shell pulls it off:

The reason this works is an assumption about descriptor management: UNIX starts looking for free file descriptors at zero, so after close(STDOUT_FILENO), the very next open() receives fd 1 — and everything wc prints via standard output flows into the file. Figure 5.4 is a program doing exactly this:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <fcntl.h>
#include <sys/wait.h>

int main(int argc, char *argv[]) {
  int rc = fork();
  if (rc < 0) {
    // fork failed
    fprintf(stderr, "fork failed\n");
    exit(1);
  } else if (rc == 0) {
    // child: redirect standard output to a file
    close(STDOUT_FILENO);
    open("./p4.output", O_CREAT|O_WRONLY|O_TRUNC, S_IRWXU);

    // now exec "wc"...
    char *myargs[3];
    myargs[0] = strdup("wc");   // program: wc (word count)
    myargs[1] = strdup("p4.c"); // arg: file to count
    myargs[2] = NULL;           // mark end of array
    execvp(myargs[0], myargs); // runs word count
  } else {
    // parent goes down this path (main)
    int rc_wait = wait(NULL);
  }
  return 0;
}

Figure 5.4: All Of The Above With Redirection (p4.c)

prompt> ./p4
prompt> cat p4.output
      32     109     846 p4.c
prompt>

Two tidbits: running p4 looks like nothing happened — but fork, exec, and wc all ran; the output just went to the file. And cat proves it got there. Cool, right?

Pipes pipe An in-kernel queue connecting one process's output to another's input, created with pipe(); the plumbing behind cmd | cmd chains. defined in ch. 5 — open in glossary work the same way, via the pipe() system call: one process’s output is connected to an in-kernel queue, and another process’s input to that same queue:

5.5 Process Control And Users

Beyond fork/exec/wait, UNIX offers a wider control surface. The kill() system call sends signals signal The UNIX mechanism for delivering external events to processes (SIGINT from control-c, SIGTSTP from control-z, …); sent with kill(), caught with signal(). defined in ch. 5 — open in glossary to a process — pause, die, and other imperatives. Shell keystrokes are wired to signals: control-c sends SIGINT (interrupt — normally terminates), control-z sends SIGTSTP (stop — pause, resume later with fg). A process can signal() to catch signals and run a handler when one arrives; whole process groups can be signaled at once.

Which raises a security question: who may signal whom? Enter the user user A logged-in identity that may launch and control only its own processes; the OS parcels resources among users. defined in ch. 5 — open in glossary : you log in with a password, gain access to your resources, and can control (pause, kill…) only your own processes; the OS parcels CPU, memory, and disk among users. And for administration there is the superuser superuser The administrative user (root) who can control any process and run powerful commands; use sparingly. defined in ch. 5 — open in glossary (root):

5.6 Useful Tools

Get to know: ps (which processes are running), top (processes and the resources they eat — comically, top often reports itself as the top resource hog), kill and the friendlier killall (send signals from the command line — careful not to kill your window manager), and a CPU meter of your choice for a glanceable view of system load.

5.7 Summary

fork(), exec(), and wait() create and control UNIX processes; signals and users govern them; the shell composes them into redirection, pipes, and every command you’ve ever typed. This only skims the surface — Stevens & Rago’s Advanced Programming in the UNIX Environment is the book for the nuances (Process Control, Process Relationships, Signals).