A process is not a command

You type grep and press Enter. Something runs. We call that something a process, and then we talk as if the word were obvious.

It isn't. A command is the text you typed. A process is a live thing the operating system is managing — an ID, some memory, open files, a parent, a place in a family tree. The shell is the translator between those two worlds.

This lesson walks that translation top to bottom. Each step introduces a few words, shows them in a terminal, and tells you what every column means. Keep a real terminal open if you want; every session has a Copy button. On macOS there is no /proc — use the macOS toggle where you see one.

By the end you should be able to answer, in plain language: what is a process, how does a command become one, what is a file descriptor, why pipes block, and why killing a parent does not kill its children.

1. Your shell is already a process

Before you type anything, your terminal is already talking to a running program: your shell (zsh, bash, fish…). That shell is a process.

Two words you need right now:

• PID — process ID. A number the kernel gives each living process so it can tell them apart. Like a ticket number.
• PPID — parent PID. Which process created this one. Your shell was started by your terminal app (or by login / ssh).

$$ is shell shorthand for “my own PID.”

So: the thing reading your keystrokes is not “the computer.” It is one process, with a number, and a parent.

2. What you type is shell language

When you write:

grep localhost < /etc/hosts

it looks like grep is being told about < and a filename. It isn't.

• A redirect (<, >) is an instruction to the shell: “before you start the program, attach this file as its input/output.”
• A pipe (|) is also an instruction to the shell: “connect program A's output to program B's input.”

The program only sees its arguments (the words after the command name). It never receives < or |.

Hold that idea. Next we watch the shell actually create a process to run the command.

3. One command, two steps: make a process, then load a program

In your head, “run grep” is one action. Unix does it in two:

1. Make a new process — usually by fork (or a close cousin). Think: photocopy the shell. The copy is a child. It gets a new PID. It still starts life running the shell's program for a moment.
2. Load the real program — exec. The child throws away the shell's code and becomes grep. Same PID. New program.

Two more words:

• fork — create another running identity (a child process).
• exec — replace the program inside an existing process. Does not create a new PID.

For a redirect, between fork and exec the child also opens the file and attaches it as input. That attach step uses a file descriptor — we define that fully in the next section. For now: “a numbered handle the process uses to read/write.”

The recording below is a guided trace of those steps. You do not need to memorize syscall names. Read the plain-English notes under each line.

Checkpoint: a command is text. A process is a numbered living object. Fork makes the object. Exec changes what program it is running.

4. A file descriptor is a coat-check number

When any program opens a file (or a pipe, or a network connection), the kernel does not hand it the file itself. It hands back a small integer: 0, 1, 2, 3…

That integer is a file descriptor (often shortened to fd).

Coat-check metaphor:

• the number is your tag (the fd);
• the cloakroom ledger remembers what you checked in;
• the coat is the real thing (file, pipe, terminal).

Every process starts with three tags already issued:

• fd 0 — stdin — where the process reads input
• fd 1 — stdout — where it writes normal output
• fd 2 — stderr — where it writes errors

This is why redirects work. grep always writes to fd 1. The shell can point fd 1 at a file, a pipe, or your terminal before grep starts. grep does not care.

Checkpoint: programs talk to the world through small integers. The shell can rewire those integers without changing the program.

5. A pipe is a small waiting room for bytes

A pipe is a kernel-managed buffer between two processes:

writer  →  [ small buffer ]  →  reader

Rules you can feel:

• If the buffer is full, the writer pauses inside write until space appears.
• If the buffer is empty but a writer still exists, the reader pauses inside read.
• If the buffer is empty and every writer has closed its end, the reader gets end-of-file (EOF) — “no more data is coming.”

That automatic pause is backpressure. Nobody sends a “slow down” message.

The classic footgun: if some process accidentally keeps the write end open, the reader may wait forever for EOF that never comes.

Checkpoint: pipes are not teleports. They are small buffers with blocking and a clear “everyone closed” signal.

6. Exiting is only half of dying

When a process finishes, the kernel frees almost everything — but keeps a tiny record: “this PID exited, here is its status.” That leftover record is a zombie. It runs no code. It just waits for the parent to read the status (via wait / waitpid). That pickup is called reaping.

If the parent dies first, the child is reparented (often to PID 1), and someone else becomes responsible for reaping.

You do not need to hunt zombies day to day. You need the idea: exit ≠ gone from the kernel's books until a parent collects the status.

7. Signals, and why your kids don't die when you do

A signal is a short kernel message to a process: “something happened.”

The ones you will actually meet:

• SIGINT — you pressed Ctrl-C
• SIGTERM — please shut down cleanly
• SIGKILL — die immediately (cannot be caught)

SIGTERM first, SIGKILL only if it will not leave. Always collect the exit status afterward when you are the parent.

Now the trap. Suppose:

your shell
  └── build (PID 901)
        └── worker (PID 902)

You kill PID 901. Does 902 die? No. Parentage is a birth record, not a cascading delete. 902 keeps running and gets a new parent.

To stop a whole job, the shell puts related processes in a process group (shared PGID). Then you can signal the group at once. In the kill command, a negative number means “the group,” not “one PID.”

Why Ctrl-C hits the right program

Your shell is still alive when you hit Ctrl-C during a command. Why doesn't the shell die?

Because the terminal tracks a foreground process group — whoever currently “has the mic.” Ctrl-C becomes SIGINT delivered to that group, not to every process on the machine. The shell hands the mic to the job, and takes it back when the job finishes.

8. A PTY is a fake terminal (short version)

Long ago a terminal was physical hardware. Today your Terminal.app / iTerm / SSH session pretends to be one using a pseudo-terminal (PTY):

• master side — owned by the terminal app;
• slave side — what the shell thinks is “the terminal.”

Programs often ask “am I talking to a real terminal?” (isatty). If the answer is no (for example, input is a pipe), they change behavior: less color, no interactive editing, and so on.

So if you want a program to behave interactively inside a sandbox, two plain pipes are not enough. You need a PTY. That detail matters later for command runners and microVMs — file it away.

Why this comes before microVMs

A virtual machine does not replace any of this.

Inside the guest, Linux still creates processes, hands out file descriptors, blocks on pipes, delivers signals, and reaps children. The host does not waitpid for programs inside the guest — the guest kernel does.

Later, when Firecracker shows up, the useful question is:

Which of these jobs belong to the guest, which belong to the host, and what crosses the boundary?

Without today's picture, a microVM looks like one magic box. With it, you see two ordinary layers using the same rules.

What to keep

If only five distinctions stick, make them these:

1. Command (text) vs process (living kernel object with a PID).
2. Fork (new identity) vs exec (same identity, new program).
3. File descriptor (the number) vs the file/pipe/terminal behind it.
4. Parent (who created you) vs process group (who shares a job signal).
5. SIGTERM (please leave) vs SIGKILL (you are gone).

Next lesson: memory that does not exist yet — why an address is not the same thing as RAM.