A Linux server is administered by editing text files. A service's configuration is text, the records it produces are text, Tramontana's booking inventory is semicolon-separated text, and even the information the kernel exposes in /proc is text. The Unix philosophy you met in Module 1 — "plain text as the universal interface" — has this very concrete consequence: half of the work of administration consists of reading and modifying text files.

This lesson gives you the two halves of that skill. The first, viewing content without opening anything: which command to use for a three-line file, which one for a two-million-line file, and which one for a log that is growing right now while Marta asks you what is going on. The second, editing: nano in full, because it is what you will use every day, and the bare minimum of vim, because the day you log into a freshly installed server or a container it may be the only thing there.

And in between, a convention the course adopts from here on and never abandons: before editing a configuration file, you make a copy.

1. cat and tac: the whole file at once
2. less: the real viewer
3. head and tail: the ends
4. Following a file live: tail -f and tail -F
5. nl and wc: numbering and counting
6. A survey of terminal editors
7. nano in full
8. Survival vim
9. The golden rule: back up before editing
10. Files that are not text: file, strings, xxd and reset
11. Comparing versions: diff and sdiff

cat (concatenate) dumps one or more files to the screen:

Its name comes from its original purpose, which was not to display but to concatenate:

Useful options:

-A is an underrated diagnostic tool:

Those ^M are Windows carriage returns. The $ marks the real end of line. It is the same pathology file detected with "CRLF line terminators" in lesson 02-03, seen now character by character. A service that reads port=8080\r will try to open a port called 8080\r and will fail with a message that helps nobody.

There is an established expression in Unix culture, Useless Use of Cat (UUOC), for this:

grep knows how to open files. Putting a cat in front creates an extra process and a pipe for nothing. With a small file it makes no difference; with one of several gigabytes, the cat forces the whole contents to be read and pushed through the pipe instead of letting grep read it directly.

This is not purism: the practical reason is that many tools lose functionality when they receive their input through a pipe instead of a file name. grep given a file can tell you the line number and the file name; through a pipe it only sees an anonymous stream. And wc -l file prints the name, whereas cat file | wc -l does not.

That said, there is a legitimate use: when you really are concatenating several files, or when you are building a chain exploratively and clarity matters more to you than performance.

The honest rule: cat is for files that fit on the screen. For a large file, cat throws thousands of lines at you and you only see the last twenty-five. That is what less is for.

tac is cat backwards: it shows the file starting from the last line.

It sounds like a curiosity and it is very useful with logs, because the most recent entries are at the end and tac puts them on top.

less shows a file page by page, without loading it entirely into memory. That last point is the important one: it opens a 10 GB file instantly, because it only reads what it is displaying.

You already know the keystrokes from lesson 02-02, because man uses less underneath. Here they are in full, including the ones that only make sense on files:

Command-line options worth knowing:

-S deserves an explanation. By default, less breaks long lines so that they fit, and a single line can take up five rows of the screen. In a log with long lines that makes reading impossible. With -S each line occupies one row and the rest stays off-screen; you see it by scrolling with the left and right arrows. For an access.log with two-hundred-character lines, -S is the difference between being able to read it and not.

& is the hidden gem. Inside less, type &ERROR and Enter: the screen shows only the lines containing "ERROR", hiding the rest. It is an instant filter without leaving the viewer. You clear it with & and a blank Enter.

+F turns less into a tail -f with superpowers: it follows the file live, and with Ctrl+C you leave follow mode and can search and navigate through what has already been written, without closing anything. With F you go back to following. It is the best tool there is for watching a log during an incident.

more is the original Unix pager. It is still installed for compatibility:

more's limitation was brutal: if you went one line too far, there was no going back. You had to reopen the file from the beginning. less was born precisely to fix that, and hence its name, a play on the English saying "less is more".

Today there is no reason to use more, except one: on a minimal system or in rescue mode less may not be installed while more is. Just know that it exists.

One behaviour of less worth knowing about and sometimes disabling: on exit it clears the screen, leaving no trace of what you saw. If you prefer the content to stay, there is the -X option. And if you want it not to paginate when the content fits on one screen, -F (the capital option, distinct from the F key used inside). The combination less -FX is the one many administrators leave configured by default.

You hardly ever need the whole file: you need the beginning or the end.

Ten lines by default in both commands.

tail's -n +N form is the one used to skip the header of a CSV:

"From line 2 to the end" discards the header. It is a pattern you will use constantly when processing data in lesson 03-05.

-c works with bytes and is useful for peeking at an unknown file without dumping the whole thing:

With several files, both add a header giving the name:

This is the section you will use most in your professional life. When something fails in production, the first thing you do is open the log and watch it while the problem is reproduced.

The command does not finish: it stays waiting and displays each new line as the application writes it. You exit with Ctrl+C.

You already glimpsed it when settling Luis's question in lesson 02-02. Now in detail, because it is one of those things you learn through an incident if you do not learn it beforehand.

logrotate is the mechanism that stops logs growing without end: every night it renames errors.log to errors.log.1, compresses it and creates an empty errors.log. Lesson 05-06 covers it.

If you left a tail -f running, after the rotation it carries on reading a file nobody writes to any more. The screen sits still and there is no message to warn you. You can spend twenty minutes convinced that the application is not logging errors when in fact it is writing them somewhere else.

-F warns you and reattaches. For production logs, always -F.

Options that go well with it:

That second example, following the access log and the error log at the same time, is exactly how diagnosis works: you see the error and, right next to it, the HTTP request that caused it.

Where less +F beats tail -F: if while watching the log you need to search backwards for something that already happened, tail will not let you and less +F will (Ctrl+C, search with /, and F to go back to following). The rule: tail -F to monitor, less +F to investigate.

nl numbers lines in a configurable way, with more control than cat -n:

-ba numbers every line (by default it skips the empty ones), -w sets the width and -s the separator. It is useful when you want to send somebody a fragment of configuration with line numbers so that you can refer to them over the phone.

wc (word count) counts:

Three numbers: lines, words, bytes. The options pick which one:

A nuance of -c against -m that matters with Catalan and Spanish names:

Ten characters, eleven bytes: the ó takes two bytes in UTF-8. When you count the length of data fields, -m is what you want.

And a practical detail: wc -l on a CSV counts the header too. The real bookings are 25, not 26.

The sensible decision for a systems administrator is to learn nano well and just enough vim:

• nano for your day to day. It is on Ubuntu, on Debian and on most server distributions. It shows the shortcuts on screen. Nobody has ever lost time learning it.
• vim because one day there will be no nano. Minimal Docker containers, RHEL images without optional packages, systems in rescue mode, client servers with restrictive policies. All of them have vi or vim, because POSIX requires it. Logging into a downed server and not knowing how to get out of vim is a real and avoidable situation.

About VS Code or graphical editors over SSH: the Remote-SSH extension lets you edit remote files through a comfortable graphical interface. It is excellent for development. For administration it has three serious drawbacks: it installs an agent on the server (which consumes memory and may not be permitted), it does not work in rescue mode or before the system has fully booted, and it is not available when you connect from the physical console or from your phone while on call. Use it to work on the application's code; do not depend on it to administer.

emacs is an extraordinary environment, but learning it from scratch to edit four configuration files does not pay off. If you already use it, carry on.

The screen has three zones: the title at the top, the text in the middle and two rows of shortcuts at the bottom. Those two rows are the reason nano is not forgotten.

The notation is fixed and has to become second nature:

• ^ means Ctrl. ^O is Ctrl+O.
• M- means Meta, which on a modern keyboard is Alt (or Esc pressed and released beforehand). M-U is Alt+U.

With that, the bottom bar is the complete documentation, permanently visible.

Movement (besides the arrow keys, which always work):

Notice that Ctrl+A and Ctrl+E are the same as on the Bash command line. That is no coincidence: both follow the readline convention.

Editing:

To cut several lines, repeat Ctrl+K: they accumulate in the clipboard and Ctrl+U pastes them all together.

Search and replace:

The replacement with Ctrl+\ asks for the text to find, then the replacement, and for each match it asks: Y to replace this one, N to skip it, A for all of them at once.

File:

The complete basic flow: you open, edit, Ctrl+O, Enter, Ctrl+X. Five keystrokes.

If you try to exit with unsaved changes, nano asks:

Four settings that improve the experience enormously:

The two that really matter:

set nowrap stops nano automatically breaking long lines when it saves. Without it, editing a configuration file with a long directive can break it silently: the line is split in two, the service reads half a directive and fails. It is the cause of more than one wasted afternoon.

set backup saves a copy of the original file every time you save. It does not replace the convention in section 9, but it is a free extra safety net.

The goal here is not for you to master vim. It is for you to be able to edit a file and get out without wrecking anything on a machine where there is nothing else. That is about fifteen commands.

vim is not an editor where you type; it is an editor where you give orders, and one of those modes consists of typing text.

Two rules follow from this, and they solve 90% of the trouble:

1. When you open vim you are in NORMAL mode. If you type, no text appears: commands are executed.
2. Esc always brings you back to normal mode. If you are lost, press Esc twice and you are on familiar ground.

:q! is the most important command in this section. If you have ended up in vim by accident, if you have typed something you did not mean to, if you do not know what you have done: Esc, then :q!, then Enter. You get out without saving and the file is left as it was.

That :w !sudo tee % solves a very common situation: you opened /etc/tramontana/app.conf without sudo, made all your changes, and on saving it tells you the file is read-only. Instead of losing the work, that command writes it through sudo.

A and o are the ones most used when editing configuration: appending to the end of a line or opening a new line.

The logic of vim is that commands compose: d (delete) + w (word) = dw. 3 + dd = three lines. Understanding that composition is what makes people addicted to vim, and also what makes its curve steep. For survival, memorise dd, yy, p and u.

u is your parachute. Pressing it repeatedly undoes everything back to the initial state.

A breakdown of :%s/old/new/g, because every part counts:

• % — on every line of the file
• s — substitute
• /old/new/ — what for what
• g — global: every occurrence on each line, not just the first

The variant with c at the end asks before each substitution. Always use it on a production file.

vim comes with an interactive tutorial of about thirty minutes:

It is, without exaggeration, the best half-hour investment you can make in this module. It will not make you an expert, but after doing it once you will never again be trapped on a server.

A note on vi versus vim: vi is the original Unix editor and vim (Vi IMproved) is its modern version. On Ubuntu, vi is usually a link to vim. On minimal systems you can come across the real vi, with fewer features (no colours, no multiple u), but everything in this section works the same.

This is not a trick: it is a working convention that the course adopts from here on and never abandons.

Before modifying any configuration file, you make a dated copy.

$(date +%F) is command substitution: the shell runs date +%F, which returns 2026-08-18, and puts the result on the line. The full mechanism is explained in lesson 03-01; adopt it now as a formula.

Why exactly like this:

If you are going to make several changes on the same day, add the time:

The complete procedure for a configuration edit, which is what gets done in production:

Step 3 is what turns the copy into more than an insurance policy: it lets you verify your own change before applying it. That is where diff comes in, in section 11.

A warning about where to leave the copies: in some directories, leaving loose files has side effects. A .bak in /etc/sudoers.d/ or in /etc/apt/sources.list.d/ can be read by the system as if it were valid configuration. In those cases the copy goes outside the directory, for example in /home/operator/config-backups/. We will see this when we touch those directories in Module 5.

What happens: a stream of rubbish appears on screen, it beeps several times, and the terminal stops working properly. The letters you type come out as strange symbols, Enter does not move to a new line, the prompt is illegible.

The explanation is concrete and makes sense. A terminal interprets certain byte sequences as control commands, not as text: change colour, move the cursor, and — this is the one that causes the problem — switch the character set to graphics mode. A binary file contains arbitrary bytes, and among millions of random bytes the sequence that activates that mode will sooner or later appear. From then on, the terminal draws line-drawing symbols instead of letters.

Nothing has broken. You just have to restore the state:

Type it even if you cannot see what you are typing, and press Enter. If reset is not available:

And if nothing works, closing the SSH session and logging in again always fixes it, because the terminal is reinitialised.

Prevention: run file before opening an unknown file. It takes a second and avoids the whole problem.

less also protects you: on detecting that a file is binary it warns with "file" may be a binary file. See it anyway?.

strings looks for sequences of printable characters at least four bytes long. Real uses:

• Finding out the version of an undocumented binary.
• Finding the paths a program has compiled inside it (here you can see that it reads a configuration file).
• Seeing the error messages it can emit, which helps you interpret one you do not understand.
• In security analysis, spotting suspicious strings inside an unknown binary.

Three columns: the offset in hexadecimal, the bytes in hexadecimal, and their representation as text (non-printable ones come out as dots).

The first four bytes, 7f 45 4c 46, are \x7fELF: the magic number that identifies a Linux executable. It is exactly what file reads to make its diagnosis.

Where xxd is genuinely useful: for seeing invisible characters in a text file that is causing trouble.

Two pathologies in plain sight:

• ef bb bf at the start is the UTF-8 BOM, an invisible marker that some Windows editors add. The program reading the file sees the first key as \xef\xbb\xbfport instead of port, does not recognise it, and uses the default value. It is a fault that can cost hours if you do not know it exists.
• 0d 0a at the end of each line is CRLF, the Windows line endings.

Neither of those two things is visible with cat, and both are obvious with xxd. That is why it is a diagnostic tool, not a curiosity.

Related utilities worth knowing: hexdump -C produces almost identical output and is available on more systems; od -c is the POSIX classic.

The most frequent question after something stops working is "what changed?". diff answers it.

That classic format is compact but cryptic. The unified format, -u, is the one used today and the one Git and every modern tool understands:

How to read it:

In this example: max_connections was raised from 50 to 200 and query_timeout was added. Two changes, identified in three seconds.

Useful options:

-r with -q is what you used to verify Luis's package in the previous lesson:

No output and code 0: identical. With differences it would be:

diff's exit codes are among those you have to look up in the manual, as you learned in lesson 02-02:

The markers in the middle:

• | — the line is different on the two sides
• < — it is only on the left
• > — it is only on the right
• (empty) — identical

sdiff is more readable for a visual review and worse for pasting into a report or applying as a patch. -w sets the total width; adjust it to your terminal.

sdiff -o output additionally enters an interactive merge mode, line by line, useful for reconciling two versions of a configuration by hand.

Related tools worth knowing: vimdiff (or vim -d) shows the differences in colour inside vim and lets you move changes from one side to the other; comm compares two sorted files line by line; and cmp compares byte by byte and is the one for binaries, where diff contributes nothing readable.

Running cat on a huge file. Thousands of lines fly past and you only see the last ones. less or tail.

Running cat on a binary. Broken terminal. file first, and reset if it is already too late.

Using tail -f on a log that rotates. It goes silent without warning. -F always in production.

Not knowing how to get out of vim. Esc, :q!, Enter. And do vimtutor once.

Editing configuration without a prior copy. The most expensive mistake in this lesson, and the easiest to avoid.

Letting nano wrap long lines. set nowrap in ~/.nanorc, or a directive split in two will break the service.

Editing a file with nano and forgetting the sudo. You do all the work and on saving you discover it is read-only. In vim there is a rescue (:w !sudo tee %); in nano you can save into /tmp with Ctrl+O and move it afterwards.

Tip: less +F instead of tail -F when you are investigating. You can pause and search backwards without closing anything.

Tip: less -S for logs with long lines. It completely changes the readability.

Tip: diff -u right after editing, always. Before reloading the service, look at what you have done. Many times you will spot an accidental change.

Tip: learn to use & inside less. Filtering without leaving the viewer is faster than any pipeline.

On /var/log/tramontana/access.log on srv-tramontana, and without using grep (which belongs to Module 3):

1. How many lines does it have?
2. Show the first and the last one.
3. Show lines 100 to 105.
4. Open the file with less, go to the end, search backwards for the first occurrence of 500 and note the line. Exit without closing the session.
5. Leave the file being followed live in a way that survives a rotation.

Marta has approved raising the application's connection limit. You have to change max_connections from 50 to 200 in /etc/tramontana/app.conf and add a line query_timeout=30.

Carry out the complete safe-editing procedure, including verification of the change, and prepare a two-line summary for Marta with exactly what you have modified. Do it first with nano and repeat it with vim for practice.

Luis sends you a /tmp/config-luis.conf that "has the same configuration but the application does not read it properly". The application returns default values instead of the ones in the file.

At first sight it looks correct. Diagnose the problem with the tools from this lesson and explain to Luis why it happens and how to avoid it in future.

Solution 1

The combination head -n 105 | tail -n 6 is the classic idiom for extracting a range: take the first 105 and out of those keep the last 6. Watch the arithmetic: lines 100 to 105 are six lines, not five.

A cleaner alternative with sed, which you will meet in lesson 03-05:

4. Inside less:

• G to go to the end.
• ?500 and Enter to search backwards (? is the reverse search; with / you would search forwards and from the end you would find nothing).
• N to keep going backwards if you want to see more matches, n to come forwards again.
• You can see the line number thanks to -N.
• q to quit.

5. Rotation-proof following:

-F, not -f. With -f, when logrotate renames the file tonight, the command will carry on watching the old file and will show nothing more, without any warning. With -F it detects the replacement, announces it and reattaches to the new file.

If you also want to be able to investigate while you monitor:

Ctrl+C to pause and search, F to go back to following.

Solution 2

The nano version:

Inside nano: Ctrl+W, type max_connections, Enter. The cursor goes to the line. Ctrl+K cuts it and you type the new one, or better: position yourself with End, delete the 50 and type 200. Then Ctrl+E (end of line), Enter for a new line, and type query_timeout=30. Save with Ctrl+O, Enter, and exit with Ctrl+X.

That cat -A confirms there are no ^M and no split lines: every line ends cleanly with $.

The vim version, starting from the restored copy:

The key sequence:

1. /max_connections and Enter — searches and places the cursor.
2. A — insert at the end of the line.
3. Delete 50 with backspace and type 200.
4. Esc — back to normal mode.
5. o — opens a new line below and enters insert mode.
6. Type query_timeout=30.
7. Esc, then :wq and Enter.

An even quicker alternative for the first change, using substitution with confirmation:

The final c makes it ask before substituting. On a production file, always with c.

Summary for Marta:

Change applied to the Tramontana Bookings configuration (/etc/tramontana/app.conf) on 18/08/2026 at 12:31: the simultaneous connection limit goes up from 50 to 200 and a maximum wait per query of 30 seconds has been added, so that a blocked query does not hold a connection indefinitely.

A copy of the previous configuration has been kept (app.conf.bak-2026-08-18), so reverting the change is a matter of seconds if we notice any unwanted effect. The change requires the service to be reloaded to take effect.

That report has what Marta needs: what changed, when, why and how to undo it.

Solution 3

cat does not show the problem because the problem is invisible by definition. Diagnosis step by step:

file already gives the complete diagnosis in one line: UTF-8 BOM and CRLF terminators. Two problems, both caused by having edited the file in a Windows editor.

What is happening exactly:

Problem 1: the BOM (ef bb bf). These are three invisible bytes at the start of the file, a marker some Windows editors insert to signal that the file is UTF-8. When the application reads the first line, it does not see the key port but \xef\xbb\xbfport. It does not recognise it as a valid key, so it uses the default value and carries on as if nothing had happened. It only affects the first line, which makes the fault even more confusing: it looks as though some options work and others do not.

Problem 2: CRLF (0d 0a). Each line ends with a carriage return plus a line feed, whereas Unix uses only the line feed. The application reads the value of timeout as 30\r, not as 30. If it expects a number, the conversion fails and it falls back to the default. And if the value were a path, it would try to open a file whose name ends in an invisible character, with an error message along the lines of No such file: /var/log/app.log in which the path looks perfectly correct.

The solution:

Now the file starts directly with port and every line ends in 0a. The final comparison:

diff marks the three lines as different even though they look identical. That baffling output is, on its own, the signature of an invisible-character problem: if diff says two identical-looking lines are different, the difference is in bytes that do not print.

What you explain to Luis:

The file is correct in its content, but not in its encoding. You edited it on Windows and the editor added two invisible things: a three-byte marker at the start of the file (the BOM) and a carriage return at the end of every line. The application reads the first key as if it had three odd characters in front of it, and every value with an invisible character at the end, so it recognises none of them and applies the defaults. Hence the impression that it "is not reading" the file.

To stop it happening again: in your Windows editor, set the line ending to LF and the encoding to UTF-8 without BOM (in VS Code you can see it and change it in the status bar, bottom right). If the file already comes from Windows, dos2unix fixes it in one command. And to check before taking anything on trust, file filename tells you in one line.

One extra piece of advice: it is safer to edit configuration files directly on the server with nano or vim than to bring them over, edit them on Windows and send them back. Every round trip is an opportunity for these characters to slip in.

This case is a good example of a general principle: when something "should work" and does not, look at the bytes. The three tools in this lesson — file, cat -A and xxd — solve in a minute a class of problem that can cost you a whole afternoon.

You now know how to read and write the contents of files, which is the raw material of systems administration.

• cat for what fits on the screen, tac to reverse it, and you know what the "useless use of cat" is and why it matters beyond purism.
• less is the real viewer: it opens huge files instantly, searches with /, filters with &, stops wrapping lines with -S and follows logs live with +F without giving up the ability to search backwards. more has been superseded.
• head and tail for the ends, with -n +2 to skip headers, and tail -F instead of -f whenever a log might rotate.
• nl and wc to number and count, with the distinction between bytes and characters that matters in UTF-8.
• You know the survey of editors and the sensible decision: nano every day, just enough vim not to get locked in.
• nano in full, with how to read its shortcut bar (^ is Ctrl, M- is Alt) and a minimal ~/.nanorc where set nowrap avoids breaking configurations.
• Survival vim: modes, Esc as the emergency exit, :q! as the parachute, dd/yy/p/u, /search, :%s/a/b/gc and vimtutor still to be done once.
• The convention we adopt from here on: cp file file.bak-$(date +%F) before editing, and diff -u afterwards to verify the change.
• file, strings, xxd for what is not text, reset to recover the terminal, and the habit of checking before opening.
• diff -u to find out what changed, with its unified format read line by line, and sdiff to review it side by side.

You have worked through the whole module with file names, taking for granted that each name corresponds to one file. In the next lesson, Hard and Symbolic Links, that assumption breaks: you will see that the name and the content are separate things, that one and the same file can have several names at once, and that there are files whose content is simply the path of another. You will understand what an inode is, why the link count of a directory is never 1, why /bin appears with an arrow in tree, and you will design the deployment pattern with which Tramontana will turn a release into production and a rollback into an instantaneous change of link.