Reading and Searching Files

In this chapter

We'll learn to read files from the terminal — cat, less, head and tail, including watching a log live with tail -f — and to search inside them with grep.

12–14 min

The Problem in Real Life

Anna types cat app.log. The terminal explodes: thousands of lines fly past for almost a minute. When it stops, she's looking at the last screen of a 200,000-line file, with no idea where the error was.

John laughs. "Everybody does that once. cat is for small files. For logs, you need the right tool for the question you're asking."

Don't read the whole log. Ask it a question.

John

Scrolling Through Everything vs. Asking the File a Question

Logs are huge

A busy app writes hundreds of thousands of lines a day. You can't read them all.

The newest lines matter most

When something just broke, the answer is usually at the end of the log.

Find the needle

One error line hides among thousands of normal ones. You need to search, not scroll.

Different questions need different tools. Here are the five John uses every day:

cat — concatenate. Prints a whole file to the screen at once. Perfect for short files like a config file: cat config.json. Terrible for big logs.
less — opens a file one screen at a time, so you can scroll. Use the arrow keys or Space to move, type / followed by a word to search for it, n to jump to the next match, and q to quit. It doesn't load the whole file at once, so it works even on huge files.
head — shows the first lines of a file (10 by default). head -n 20 app.log shows the first 20. Good for checking what a file looks like.
tail — shows the last lines of a file. tail -n 50 app.log shows the last 50 — usually the most recent events.
tail -f — follow. Shows the last lines and then keeps watching, printing each new line the moment the app writes it. This is how you watch a live app. Press Ctrl+C to stop watching.
grep — searches for text and prints only the lines that contain it. grep ERROR app.log shows every line with "ERROR" in it. Useful options: -i (ignore upper/lower case), -n (show line numbers), -c (just count matching lines), -r (search every file inside a folder), -v (show lines that don't match).

Table — Which command for which question?

Your question	Command
What's in this small config file?	cat config.json
Let me browse and search this big file	less app.log
What does the start of this file look like?	head -n 20 app.log
What happened most recently?	tail -n 50 app.log
What is the app doing right now?	tail -f app.log
Which lines mention an error?	grep ERROR app.log
How many errors were there?	grep -c ERROR app.log

Table — Reading one log line

Part	Example	Meaning
Date and time	2026-11-14 10:41:07	When it happened
Level	ERROR	How serious (DEBUG < INFO < WARN < ERROR)
Source	[booking]	Which part of the app wrote it
Message	booking failed: seat_id missing	What happened

Asking the log questions

head -n 3 app-today.log
# 2026-11-14 00:00:01 INFO  [server] BlueTicket started on port 3000
# 2026-11-14 00:00:04 INFO  [booking] seat A12 held for user 8812
# 2026-11-14 00:00:09 INFO  [booking] seat A12 sold to user 8812

grep -c ERROR app-today.log
# 37

grep -n -i "seat_id" app-today.log
# 18204:2026-11-14 10:39:55 ERROR [booking] booking failed: seat_id missing

tail -f /var/log/blueticket/app.log    # watch live; Ctrl+C to stop

What a log line looks like: Each line usually starts with a date and time, then a level — how serious it is — then the message. Common levels from least to most serious: DEBUG, INFO, WARN, ERROR. That's why searching for ERROR is such a good first move.

Anna tries it on her safe copy. tail -n 20 app-today.log shows normal booking lines. grep -c ERROR app-today.log says 37 — thirty-seven errors today. grep -n ERROR app-today.log | tail -n 5... she isn't sure what the | does yet, but John says to try it. The five most recent errors appear, all saying the same thing: ERROR booking failed: seat_id missing.

Now she wants to watch it happen live. She opens the real log with tail -f /var/log/blueticket/app.log, asks the tester to try a booking, and watches the new lines appear in real time — including the error, the instant it happens. It always comes right after a request from the mobile app, never from the website.

Key Takeaway

Pick the reading tool for your question: cat for small files, less to scroll and search big ones, head and tail for the start and end, tail -f to watch a log live, and grep to find just the lines that matter. Never read a big log from top to bottom — ask it a question.

Why This Matters

Reading logs is how almost every production problem gets solved. When something breaks at BlueTicket — a failed payment, a slow page, a crash at 3 AM (Act 10) — the first move is the same: open the logs and ask them a question. In Act 19, Anna will use exactly these commands during her first bad deployment.

Anna has found the error and a strong clue: it only happens for mobile bookings. But she used a mystery symbol, |, without understanding it — and she wants to save the error lines to a file to send to the mobile team. That's the last piece of the command line: connecting commands together.