Reading and editing files: less, tail -f and vim

You’ll read a test file in different ways, watch a live log, then edit a small config in vim from start to finish. Every file in this lab lives in ~/lab12 except the log you watch, which the system writes for you.

1Make a test config and a long file

Paste this whole block:

mkdir -p ~/lab12 && cd ~/lab12
printf '%s\n' '# demo app config' 'listen_port = 8080' 'log_level = info' 'max_clients = 200' 'data_dir = /srv/app/data' > app.conf
seq 1 100 | sed 's/^/line /' > big.txt
cat -n app.conf

You should see this:

     1	# demo app config
     2	listen_port = 8080
     3	log_level = info
     4	max_clients = 200
     5	data_dir = /srv/app/data

cat -n numbers every line, which helps when someone on a call says “look at line 4”. The other two commands built a 100-line file so you have something to scroll through.

✅ Checkpoint: app.conf shows five numbered lines.

2Read the start and the end

Run this:

head -n 3 big.txt
tail -n 2 big.txt

You should see this:

line 1
line 2
line 3
line 99
line 100

On a large log, tail -n 100 is usually the first thing you run, because the newest lines are at the bottom.

✅ Checkpoint: You saw lines 1 to 3 and lines 99 and 100.

3Page through a file with less

Run this:

less big.txt

Inside less, press Space a few times, then G to jump to line 100 and g to jump back to the top. Type /line 42 and press Enter to search, n for the next match, and q to quit. Nothing you press inside less can change the file.

Try the same keys on a real log: sudo less /var/log/messages on rocky01 or sudo less /var/log/syslog on ubu01. Press Shift+F inside less to follow new lines like tail -f, and Ctrl+C to stop following.

✅ Checkpoint: You found line 42 with / and left less with q.

4Spot hidden characters

Run this:

printf 'a\tb \r\n' > win.txt
cat -A win.txt

You should see this:

a^Ib ^M$

^I is a tab, the space before ^M is a trailing space, ^M is a Windows carriage return and $ marks the end of the line. A script copied from a Windows laptop with ^M on every line fails with confusing errors, and cat -A shows you why in one second.

✅ Checkpoint: You can name what ^I, ^M and $ mean.

5Watch a log live with tail -f

Open a second SSH session to the same VM. In the first one, start watching the system log:

sudo tail -f /var/log/messages

sudo tail -f /var/log/syslog

In the second session, write three test lines into the log:

Run this:

for i in 1 2 3; do logger "health check $i"; sleep 5; done

On ubu01 the first session should show something like this:

2026-10-27T11:02:14.218733+05:30 ubu01 student: health check 1
2026-10-27T11:02:19.224961+05:30 ubu01 student: health check 2
2026-10-27T11:02:24.231508+05:30 ubu01 student: health check 3

On rocky01:

Oct 27 11:02:14 rocky01 student[2214]: health check 1
Oct 27 11:02:19 rocky01 student[2219]: health check 2
Oct 27 11:02:24 rocky01 student[2224]: health check 3

The lines appear five seconds apart, as they’re written. Ubuntu prints the RFC 3339 timestamp (date, time with microseconds and the time zone), Rocky still uses the traditional format. Press Ctrl+C to stop tail; it doesn’t touch the log.

No such file? Some trimmed-down installs leave out rsyslog, so only the journal has the logs. Follow it with sudo journalctl -f instead, or install rsyslog (sudo dnf install rsyslog or sudo apt install rsyslog).

✅ Checkpoint: All three “health check” lines appeared in the tail window while the loop ran.

6Open the file in vim and find your way around

On rocky01, install the full vim first (it also gives you vimtutor): sudo dnf install -y vim-enhanced. ubu01 already has it.

Run this:

vim app.conf

You’re in Normal mode. Type :set number and press Enter to show line numbers. Move with the arrow keys (or h j k l), press gg for the first line and G for the last, and type :2 and Enter to jump to line 2.

Search with /max and Enter.

✅ Checkpoint: Line numbers show on the left and the cursor sits on the max_clients line.

7Change a value, add a line, save

Still in vim, do these in order:

The bottom line of vim should show something like this:

"app.conf" 6L, 121B written

6L and 121B are the new line and byte counts. Now quit with :q and check the file from the shell:

cat app.conf

# demo app config
listen_port = 9090
log_level = info
max_clients = 200
data_dir = /srv/app/data
log_dir = /srv/app/logs

✅ Checkpoint: cat shows listen_port = 9090 and the new log_dir line.

8Delete, copy, paste and undo

Run this:

vim app.conf

You’ll see E37 in the bottom line because the pasted line is in the buffer but not in the file. (If you had undone every change, vim would let plain :q through.) :q! is your emergency exit whenever an edit goes wrong.

Check the file did not change:

cat app.conf

✅ Checkpoint: app.conf still has six lines with listen_port = 9090.

9Edit a system file the safe way

Now the full routine on a real config. You’ll add a harmless comment to the SSH server config, check it and keep the backup.

Run this:

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)
sudo vim /etc/ssh/sshd_config

Press G, then o, type # Lesson 12 test edit, press Esc and save with :wq. Then test the file:

sudo sshd -t && echo "sshd config OK"
ls -l /etc/ssh/sshd_config*

You should see something like this (on rocky01):

sshd config OK
-rw-------. 1 root root 3667 Oct 27 11:20 /etc/ssh/sshd_config
-rw-------. 1 root root 3644 Oct 21 09:14 /etc/ssh/sshd_config.bak.2026-10-27

sshd -t printed nothing, so the && let the echo run. The backup kept the original owner, mode and date because of cp -a. A comment needs no restart, but for a real change you’d now reload sshd and test a new login from a second terminal before closing the first.

The same idea for sudo: never open /etc/sudoers with a plain editor. sudo visudo edits a temporary copy and refuses to save a broken file. You’ll write your own sudo rules in Lesson 16.

✅ Checkpoint: sshd -t reports OK and a dated backup of sshd_config exists.

10Learn the rest with vimtutor

Run this:

vimtutor

vimtutor opens a practice copy of a lesson file and walks you through moving, deleting, changing and searching, in about 30 minutes. Do it once now and once again next week; after that, vim stops feeling strange.

✅ Checkpoint: You finished at least Lesson 1 and 2 of vimtutor.