P-1.4 Files, Processes and What the Operating System Does

What this is and why it exists

Programs do not run on hardware. They run on an operating system, and it decides almost everything about what they can see and do.

That is not a detail for later. The small set of ideas here turns up in every language you will use and every deployment you will ship to. Processes, the file system, the three standard streams, exit codes, environment values. They are the vocabulary in which running software is discussed.

One confusion is worth naming at the start, because it causes a surprising share of first deployment failures. A file path is not a name, it is a lookup. What it finds depends on where the program was started from.

The vocabulary

• Process — one running program, with its own memory and its own view of the machine.
• File system — the tree of directories and files the operating system presents.
• Absolute path — a location written from the root, meaning the same thing from anywhere.
• Relative path — a location resolved against the directory the process is in.
• Working directory — the directory a process counts as "here".
• Standard input, output and error — the three streams every process starts with open.
• Exit code — the number a program returns to say whether it worked.
• Environment value — a named setting the operating system hands to a process.
• Permissions — the rules deciding what a process may read, write or run.

The mental model

Starting a program creates a process. The operating system gives it its own memory and its own handles on files, and two runs of the same program share nothing by default. That isolation is what makes it safe to run several at once, and it is why one crashing does not take the others with it.

The file system is a tree, and paths into it come in two kinds. An absolute path is written from the root and means the same thing wherever it is used. A relative path is resolved against the process's working directory. So the same string names different files depending on where the program was run from. Code that works from the project directory and fails when a scheduler runs it elsewhere is almost always this. It is worth suspecting first.

Every process starts with three streams already open: input, output, and error. This is the reason programs can be chained together without knowing anything about each other. One writes to output, the next reads from input. Neither has to be designed for the other. The error stream matters more than it looks. Sending diagnostics there rather than to output keeps your messages out of the data the next program reads.

When a process finishes it returns a number. Zero conventionally means it worked and anything else means it did not. That number is how scripts, schedulers and build systems decide what to do next. A program that fails silently with a zero exit code causes trouble far away from itself.

Environment values are named settings the operating system hands to a process. They are how configuration reaches a program without being written into it. And how a secret reaches a program without being committed alongside the code.

Permissions sit across all of it, deciding what this process, run by this user, may read, write or execute. A program cannot reach past them by trying harder.

What you should now be able to explain or do

Say what a process is and why two runs of one program share nothing. Explain why a relative path can name different files on different runs, and say what decides it. Name the three standard streams and say why diagnostics belong on the error one. Say what an exit code is for and who reads it. Explain how configuration and secrets reach a program without being written into it. Say what permissions decide and why a program cannot argue with them.

Check yourself