Viewing and Editing Files in the Terminal

You SSH into a server, a request is failing, and the answer is sitting in a log file somewhere. There's no editor, no file browser, just a blinking prompt. Knowing how to read that file fast, and tweak a config line without leaving the terminal, is the difference between fixing it in thirty seconds and flailing for ten minutes. That's this whole lesson.

We'll use one sample file the whole way through. Create it so you can follow along:

cat > app.log <<'EOF'
2026-08-02 09:14:02 INFO  server started on :8080
2026-08-02 09:14:05 INFO  GET /health 200 3ms
2026-08-02 09:15:11 WARN  slow query took 812ms
2026-08-02 09:15:12 INFO  GET /users 200 121ms
2026-08-02 09:16:40 ERROR db connection refused
2026-08-02 09:16:41 INFO  retrying in 2s
2026-08-02 09:16:43 INFO  db connection restored
EOF

That cat > trick writes everything up to EOF into a new file. Handy, but mostly we use cat to read, which is next.

cat: dump a whole file

cat prints a file straight to the terminal. No paging, no fuss.

cat app.log

2026-08-02 09:14:02 INFO  server started on :8080
2026-08-02 09:14:05 INFO  GET /health 200 3ms
2026-08-02 09:15:11 WARN  slow query took 812ms
2026-08-02 09:15:12 INFO  GET /users 200 121ms
2026-08-02 09:16:40 ERROR db connection refused
2026-08-02 09:16:41 INFO  retrying in 2s
2026-08-02 09:16:43 INFO  db connection restored

The name is short for concatenate, because its original job was joining files together. Pass it two and it prints them back to back:

cat header.txt body.txt

That's the whole feature. There's no separator, it just runs one file into the next. cat is perfect for short files: a .env, a small config, a seven-line log. But run it on a 50,000-line log and it'll fire the entire thing past your screen and dump you at the bottom, with no way to scroll back through it sanely. For anything that doesn't fit on one screen, you want a pager.

less: read big files one screen at a time

less opens a file in a scrollable view instead of dumping it. You move around, you search, you quit. The file never scrolls off into nowhere.

less app.log

Now you're inside less, and your keyboard drives it:

• Space or f pages down, b pages up
• arrow keys or j/k scroll one line at a time
• g jumps to the top, G jumps to the bottom
• /error searches forward for "error", then n for the next match, N for the previous
• q quits and gets your prompt back

That search is the killer feature. Open a 10,000-line log, type /ERROR, hit Enter, and you're staring at the first error with n ready to walk you through the rest. Searches are case-sensitive by default. Add -i when you launch (less -i app.log) to make them case-insensitive.

head and tail: just the ends

Often you don't want the whole file, only a peek. head shows the first 10 lines, tail shows the last 10.

head app.log

2026-08-02 09:14:02 INFO  server started on :8080
2026-08-02 09:14:05 INFO  GET /health 200 3ms
2026-08-02 09:15:11 WARN  slow query took 812ms
2026-08-02 09:15:12 INFO  GET /users 200 121ms
2026-08-02 09:16:40 ERROR db connection refused
2026-08-02 09:16:41 INFO  retrying in 2s
2026-08-02 09:16:43 INFO  db connection restored

Our file is only seven lines, so head shows all of it. Control the count with -n:

tail -n 3 app.log

2026-08-02 09:16:40 ERROR db connection refused
2026-08-02 09:16:41 INFO  retrying in 2s
2026-08-02 09:16:43 INFO  db connection restored

tail is the one you'll reach for constantly, because the newest log lines are at the bottom of the file. The most recent thing your app did is the last line. And then there's the flag that earns tail its keep: -f, for follow.

tail -f app.log

Instead of printing the end and quitting, tail -f parks at the bottom and prints new lines as they're written. It's a live feed of your log. Start it in one terminal, hit your app in another, and watch the requests stream in real time:

2026-08-02 09:16:43 INFO  db connection restored
2026-08-02 09:18:01 INFO  GET /orders 200 64ms
2026-08-02 09:18:09 WARN  cache miss for key user:42

This is how you debug a running service. No refreshing, no re-running cat. You watch the failure happen. Quit the follow with Ctrl-C. A common combo is tail -f plus a filter (you'll meet pipes in the next lesson): show me only the errors as they happen, and ignore the rest.

wc: count lines, words, bytes

wc (word count) is a tiny tool that tells you how big something is. By itself it prints lines, words, and bytes:

wc app.log

       7      49     330 app.log

That's 7 lines, 49 words, 330 bytes. The flag you'll use most is -l for just the line count:

wc -l app.log

7 app.log

On its own that's mildly useful. Where wc -l shines is on the end of a pipe. "How many lines mention ERROR?" becomes a one-liner once you can feed one command's output into the next. That's the next lesson's whole story.

Quick edits with nano

Reading is half the job. Sooner or later you need to change one line in a config file on a box that has no graphical editor. nano is the friendliest way to do it. It shows its shortcuts right on screen, so there's nothing to memorize.

nano app.log

You're now in the editor. Type and arrow around like any text box, and there's no weird "mode" to fight. At the bottom you'll see a bar like this:

^G Get Help   ^O Write Out   ^W Where Is   ^K Cut Text
^X Exit       ^R Read File   ^\ Replace    ^U Paste

The ^ means the Ctrl key. The only two you truly need:

• Ctrl-O writes out (saves). It asks you to confirm the filename, so press Enter to keep it.
• Ctrl-X exits. If you have unsaved changes it'll prompt you to save first (Y then Enter).

So the full edit loop is: open with nano file, change your line, Ctrl-O then Enter to save, Ctrl-X to leave. That's enough to fix a port number or flip a feature flag on a remote server, which covers most real edits you'll make from a terminal.

When to use what

Reach for the tool that matches the file:

• cat for short files you want to see all of at once, or joining files together.
• less for anything big, or anything you need to search and scroll.
• head / tail for just the start or end, with tail -f to watch a live log.
• wc -l to count lines (and it gets handy once you pipe into it).
• nano for a quick, no-surprises edit, and vim when a tool forces it on you (escape with :q!).

These five cover nearly everything you'll do to a file from the command line day to day. For the exhaustive flag list, the GNU coreutils manual documents cat, head, tail, and wc in full.

The real jump is next. Right now each command works on a file and prints to your screen. The moment you can take one command's output and feed it straight into another (cat a log, filter it for errors, count the result, all in one line) the terminal stops being a set of separate tools and becomes a pipeline. That's exactly where we're headed in Pipes and redirection. And if you skipped it, the previous lesson on Files and directories is what got us the files we're now reading.