What is reading a file?

The filing cabinet you never close

Picture a filing cabinet in an office. To read a document inside it, you do three things: you open the drawer, you read the paper, and you close the drawer. Every program on your computer does the same three steps when it reads a file: open, read, close. This sequence is so fundamental that every operating system on Earth works this way.

But here is something most tutorials skip: the drawer handle is not the file itself. When your operating system opens a file, it gives your program a file descriptor: a small number (like 3, 4, or 5) that acts as a handle to that open file. Your program uses this number to read the file's contents. When it is done, it closes the file descriptor, releasing the handle.

Files are just stored bytes

A file is a sequence of bytes stored on your disk. A text file like notes.txt contains bytes that represent characters: letters, numbers, spaces, and newlines. When you "read" a file, your program asks the operating system to copy those bytes from disk into memory so it can work with them.

Here is a text file with three lines:

Hello, world!
This is line two.
Goodbye.

On disk, this is stored as a single sequence of bytes. The newline characters (\n) tell your terminal where one line ends and the next begins. Without newlines, everything would appear on a single long line.

Think of a file as a scroll of paper. The text is written continuously, and the newline character is like a mark that says "start a new line here."

File descriptors: the handles to everything

When a program starts, the operating system automatically opens three file descriptors for it:

+------+--------+----------------------------+
|  FD  |  Name  |  Purpose                   |
+------+--------+----------------------------+
|  0   | stdin  | Standard input (keyboard)  |
|  1   | stdout | Standard output (screen)   |
|  2   | stderr | Standard error (screen)    |
+------+--------+----------------------------+

stdin (file descriptor 0) is where a program reads input from, usually your keyboard. stdout (file descriptor 1) is where a program writes its normal output, usually your terminal screen. stderr (file descriptor 2) is where a program writes error messages: also your screen, but through a separate channel.

Why does this matter? When you run cat notes.txt, here is what happens under the hood:

1. The shell starts the cat program.
2. cat asks the OS to open notes.txt. The OS returns a file descriptor (say, 3).
3. cat reads bytes from file descriptor 3.
4. cat writes those bytes to file descriptor 1 (stdout: your screen).
5. cat closes file descriptor 3.

+------------+     read      +-----------+
|  notes.txt | ------------> |    cat    |
|  (FD 3)    |   (bytes)     |  program  |
+------------+               +-----+-----+
                                   |
                             write | (FD 1)
                                   v
                            +-----------+
                            |  Terminal |
                            |  (stdout) |
                            +-----------+

This open-read-write-close cycle is the foundation of everything you will learn in the next six lessons.

Why cat exists

The name cat is short for concatenate, which means "to join things together." Its original purpose was to combine multiple files into one output stream. But developers discovered that cat with a single file is the fastest way to dump a file's contents to the screen. So cat file.txt became the most common way to read a small file in the terminal.

Try this in your terminal:

$ echo "Hello from the terminal" > greeting.txt
$ cat greeting.txt
Hello from the terminal

The first command creates a file called greeting.txt with one line of text. The second command reads that file and prints its contents to your screen. Behind the scenes, cat opened the file, read its bytes, wrote them to stdout, and closed the file descriptor: all in milliseconds.

Reading vs. editing vs. executing

The terminal offers different tools for different jobs with files:

Reading is non-destructive: you cannot damage a file by reading it. This makes file-reading commands safe to experiment with. You can cat any file as many times as you want without risk.

Why this matters for Rails

Rails applications are made of dozens of files: configuration files like Gemfile and config/database.yml, route definitions in config/routes.rb, and log files in log/development.log. As a Rails developer, you will read files constantly:

• Checking which gems are installed: cat Gemfile
• Reading the last few errors in your log: tail log/development.log
• Searching through a large configuration file: less config/routes.rb
• Inspecting your Ruby version: cat .ruby-version

Mastering file-reading commands is not optional: it is a core skill you will use every day.

Common mistakes

Mistake: Trying to cat a binary file (like an image or a compiled program).
What happens: Your terminal floods with unreadable garbage characters, and sometimes your prompt gets corrupted.
Instead: Use file myimage.png first to check if a file is text or binary before reading it.

Mistake: Using cat on a massive file (thousands of lines).
What happens: Your terminal scrolls for minutes and you cannot see the beginning.
Instead: Use less for large files (you will learn this in Lesson 3) or head/tail for quick peeks.

Summary