Reading & editing files — cat, less, nano, vim survival

Reading and editing files: cat, less, nano, vim

Section 1 of 5 · ~3 min

Yesterday you moved files around. Today you look inside them and change them — the two things you do on a server more than anything else. There are two jobs here, and a different tool for each.

Reading. The bluntest tool is cat: it prints a file’s entire contents to the screen and drops you back at the prompt. That’s perfect for a short config file, or for piping one file into another command — but point it at a 2 GB log and it tries to dump all two gigabytes into your terminal at once, the classic way to freeze a session. For anything long, use less. It’s a pager: it loads only what fits on screen, so it opens instantly no matter how big the file is. Inside less you scroll with the arrows, jump to the end with G, search forward with /word, and — the command everyone forgets — quit with q. When you only want the edges of a file, head prints the first ten lines and tail the last ten; tail -f keeps printing new lines as they’re written, which is how you watch a service log live during a deploy.

Editing. For a quick change, nano is the friendly choice: its shortcuts are printed right along the bottom of the screen (^O to save — that’s Ctrl+O — and ^X to exit), so there are no modes to learn. It’s ideal for fixing one value in a config and getting out.

Then there is vim, and vim has modes — the thing that traps every beginner.

Real world: vim’s two modes trip up everyone at first. Think of a TV remote that’s also a keyboard: normally the buttons change the channel (normal mode — keys are commands), but flip one switch and those same buttons type text into the search box (insert mode). People get “stuck” in vim for exactly this reason — they press letters expecting text while the remote is still in channel-changing mode. Esc always flips back to commands, and from there :q! gets you out.

vim opens in normal mode, where letters are commands, not text. Press i to enter insert mode and type normally; press Esc to return to normal mode. From normal mode a colon starts a command: :wq writes (saves) and quits, :q quits when you’ve changed nothing, and :q! quits and discards your changes. That’s the survival kit — three commands and the Esc key.

Why bother with vim when nano is easier? Because you don’t always get a choice. vi is the one editor the POSIX standard requires, so it’s on virtually every Unix-like machine — and stripped-down production images often ship nothing else. Alpine Linux, the ~5 MB base image behind a huge share of production Docker containers, includes no nano and no full vim, only BusyBox’s tiny vi. When you SSH into a box at 2 a.m. and the config is broken, “I only know nano” is not an answer. Knowing three vim commands is the difference between fixing it and being stuck.

Hands-On Lab

Section 2 of 5 · ~3 min

Budget about 25 minutes in your Ubuntu terminal. Type every command yourself and read each output before moving on — reading is the whole skill today. Work from your home directory (cd ~ if you wandered off).

# 1. Make a small file to read. > creates/overwrites; >> appends a line.
echo "line one: hello from day 4" > notes.txt
echo "line two: appended, not overwritten" >> notes.txt
# (no output — redirection is silent; the text went into notes.txt, not your screen)

# 2. Read the whole file at once. cat = "concatenate and print".
cat notes.txt
# Output:
# line one: hello from day 4
# line two: appended, not overwritten

# 3. Build a long file to page through. seq prints 1..100000; > sends it to big.txt.
seq 1 100000 > big.txt
wc -l big.txt
# Output:
# 100000 big.txt

# 4. Open the long file in the pager. Space/arrows scroll, G jumps to the end,
#    /500 searches forward, n repeats the match, and q quits back to the prompt.
less big.txt
# (less takes over the whole screen instead of dumping 100000 lines. Press q to return here.)

# 5. Peek at just the top — head prints the first 10 lines by default.
head big.txt
# Output:
# 1
# 2
# 3
# 4
# 5
# 6
# 7
# 8
# 9
# 10

# 6. Peek at just the bottom — tail prints the last 10 lines.
tail big.txt
# Output:
# 99991
# 99992
# 99993
# 99994
# 99995
# 99996
# 99997
# 99998
# 99999
# 100000

# 7. Narrow it to only the last 3 lines with -n.
tail -n 3 big.txt
# Output:
# 99998
# 99999
# 100000

# 8. Create and edit a file in nano. Type the line: edited in nano on day 4
#    then Ctrl+O and Enter to save, Ctrl+X to exit. The shortcuts (^O Write Out, ^X Exit) are printed along the bottom.
nano hello.txt
# (nano takes over the screen; after Ctrl+O, Enter, Ctrl+X you land back at the prompt — no output)

# 9. Prove nano actually wrote the file.
cat hello.txt
# Output:
# edited in nano on day 4

# 10. Open a file in vim. It starts in NORMAL mode — press i to insert, then type: learn three vim commands: i, Esc, :wq
#     press Esc to leave insert, then type :wq and Enter to write and quit.
vim todo.txt
# (vim takes over the screen; i -> type -> Esc -> :wq -> Enter returns you to the prompt)

# 11. Confirm the vim edit stuck.
cat todo.txt
# Output:
# learn three vim commands: i, Esc, :wq

Before you close the terminal, read the last two cat outputs back and note what just happened: you created files with redirection, read them whole with cat, paged a 100,000-line file without freezing anything, peeked at both edges with head/tail, and made edits stick in both nano and vim — the everyday file loop you will run on every server from here on.

Common Errors & Fixes

Section 3 of 5 · ~3 min

These are the three that catch almost everyone in their first week of editing files on a Linux box. Each is technically correct for Ubuntu 24.04 — read the error text slowly, because parsing it is the real skill.

Common error: Editing a file in vim, then pressing Esc and typing :q to leave — vim refuses and prints a cryptic line at the bottom of the screen:

E37: No write since last change (add ! to override)

Why: vim will not silently throw away edits you have not saved. :q means “quit” but you changed the buffer, so vim stops you. The letters landing as text instead (the other classic “stuck in vim”) happen when you skip Esc — you were still in insert mode, so :q got typed into the file.

Fix: Press Esc first to guarantee you are in normal mode, then choose: :wq (or :x) to save and quit, or :q! to discard the changes and get out. The ! means “force it, I don’t care about unsaved edits.”

How you’d spot it in prod: A CI job or an SSH session that “hangs” on an editor is usually a script that opened vi/vim on a tty with no human to close it — a commit without -m, or crontab -e in a non-interactive shell. The fix is to pass the content directly (git commit -m, redirect a file in) rather than shell out to an interactive editor.

Common error: Reaching for nano inside a stripped-down container (a slim Debian image, or a minimal Ubuntu base) prints:

bash: nano: command not found

Why: nano is not part of a minimal base image — it is an extra package. Small production images ship as little as possible, so the friendly editor you rely on locally simply is not installed. On the smallest images there is no full vim either; Alpine’s ~5 MB base gives you only BusyBox vi.

Fix: Use vi (or vim) instead — it is the editor you can count on being present, which is exactly why the three-command survival kit matters. If you genuinely need nano, install it: apt-get update && apt-get install -y nano on Debian/Ubuntu, apk add nano on Alpine.

How you’d spot it in prod: command not found for a tool that “works on my laptop” almost always means the container or CI runner is more minimal than your dev box. Bake the tool into the image (a RUN apt-get install layer) rather than assuming it is there.

Common error: Opening a system file such as /etc/hosts in nano without elevated rights, typing a change, then pressing Ctrl+O to save — nano shows in its status bar:

[ Error writing /etc/hosts: Permission denied ]

Why: /etc/hosts is owned by root with mode 644, so any normal user can read it (nano opened it fine) but only root may write it. The permission check happens at save time, not open time — which is why the edit felt fine until Ctrl+O.

Fix: Edit it with root’s privileges: sudo nano /etc/hosts. Save your work elsewhere first if you have unsaved edits (Ctrl+O to a file in your home directory), because quitting without write access loses them. You will learn exactly what sudo is doing — and file ownership and the permission bits behind it — tomorrow on Day 5.

How you’d spot it in prod: Permission denied when writing a path means the process’s user lacks write rights on that file. Check the owner and mode (ls -l) and who the process runs as before reaching for sudo everywhere — the right fix is usually correct ownership on the file, not blanket privilege.

Reading & Editing Interview Questions

Section 4 of 5 · ~1 min

The four questions below come straight from real screening rounds, and this day’s answer bank renders right after this note. Cover each answer, say your own version out loud first, then compare — recalling before revealing is what makes it stick for interview day.

Go Deeper

Section 5 of 5 · ~1 min

Optional extras if you have ~30 more minutes today:

• 15 min — Run vimtutor in your terminal. It’s the interactive tutorial that ships with vim; the whole thing takes about half an hour, but the first two lessons alone teach you enough to stop fearing the editor.
• 5 min — Open a long file in less and practise searching: /error then Enter jumps to the first match, n goes to the next, N to the previous, q quits. Searching inside a paged file is a skill you’ll use on every log.
• 10 min — Read the file-handling section of the Linux for DevOps guide for the wider context on how these tools fit the daily workflow.