cat, and When Not to Use It

Part I · Module 4 · Chapter 4.1 · cat, and When Not to Use It

1. A Module That Only Looks

Module 2 taught you to find a file. Module 3 taught you to create, copy, move and delete one. What has been missing is the most common thing anyone actually does with a file: look inside it.

That is this module, and it comes with a genuine relief. Nothing in Module 4 modifies anything. Every command reads. You can point any of them at any file, get it wrong, and try again — the worst outcome is output you did not want.

There is one exception worth flagging now so it does not surprise you. Some examples in this module use > to create a demonstration file. That character is redirection, which is Module 12's subject, and it does write. It appears here only to set up an example, never as something being taught.

2. cat Prints a File

$ pwd
/home/engineer/project

$ cat notes.txt
Build runs clean on the develop branch.
Two warnings remain in the timing report.
Check with Priya before tagging.

That is the whole of the common case. cat takes a path, reads the file, and sends the contents to your screen.

Every path form from Module 2 works, since cat receives a path like any other command:

$ cat rtl/alu.sv              # relative
$ cat /etc/os-release         # absolute
$ cat ../docs/readme.md       # via the parent
$ cat ~/notes.txt             # the shell expands ~ first

When the file is not there, the familiar shape:

$ cat missing.txt
cat: missing.txt: No such file or directory

Read it with Chapter 1.3's rule — the prefix is cat:, so the program started and could not find what it was given. Chapter 2.2's advice applies: if you are sure the file exists, check pwd before anything else.

3. The Name Explains the Behaviour

cat is short for concatenate, which means join end to end. That is its actual job; printing one file is the degenerate case of joining one thing.

Give it several files and it prints them in order, with nothing between them:

$ cat part1.txt
first section

$ cat part2.txt
second section

$ cat part1.txt part2.txt
first section
second section

There is no separator, no heading and no blank line between the two. The output is exactly the first file followed by the second — which is what joining means, and is sometimes a surprise when you expected the files to be distinguishable.

That becomes genuinely useful when the output goes somewhere other than the screen:

$ cat part1.txt part2.txt > whole.txt

$ cat whole.txt
first section
second section

One file now holds the contents of both. The > is redirection — Module 12 — and is shown here because it is the reason cat has the name it does. You are not expected to use it yet.

Order is yours to choose, and it is the order you type:

$ cat header.txt body.txt footer.txt > document.txt

4. Two Options Worth Knowing

Number the lines.

$ cat -n notes.txt
     1	Build runs clean on the develop branch.
     2	Two warnings remain in the timing report.
     3	Check with Priya before tagging.

Useful when someone says "the error is on line 47" and you want to find it in a short file. For a long file, Chapter 4.2's pager does this better.

Show the characters you cannot see.

$ cat -A notes.txt
Build runs clean on the develop branch.$
Two warnings remain in the timing report.$
Check with Priya before tagging.$

Each $ marks the end of a line. That looks like trivia and is not: it is how you discover that a file has the wrong kind of line ending, which produces errors that name a character nobody can see. Chapter 4.7 is entirely about that, and this option is its main tool. On systems where -A is unavailable, cat -ve is the usual equivalent — Chapter 1.6's rule about checking the local manual applies.

5. When cat Is the Wrong Tool: Large Files

Here is the first of the two cases the chapter is named for.

$ ls -lh sim/run_042/sim.log
-rw-r--r-- 1 engineer engineer 2.4G Mar 22 09:15 sim.log

$ cat sim/run_042/sim.log

What happens: 2.4 gigabytes of text is sent to your terminal as fast as it can be drawn. It scrolls past far too quickly to read. Your terminal keeps a limited scrollback buffer — a few thousand lines, typically — so the beginning is discarded long before the end arrives. You end up with the last screenful and nothing else, after a long wait.

Nothing is damaged. The file is untouched, and Ctrl-C stops it, as Chapter 1.3 described. But you have learned nothing and spent time doing it.

The problem is not the size as such — it is that cat has no concept of stopping. It reads to the end and sends everything. Whatever you wanted to see, you wanted a part of it:

• the first lines, to see what kind of file it is → Chapter 4.3;
• the last lines, to see how a run ended → Chapter 4.3;
• a particular section you can navigate to → Chapter 4.2;
• lines containing a particular word → Module 14.

Every one of those is a better question than "show me all of it", and each has a command that answers it without moving two gigabytes through your terminal.

6. When cat Is the Wrong Tool: Files That Are Not Text

The second case is less obvious and more annoying.

$ cat /bin/ls

A program is not text. It is a file of arbitrary bytes, and your terminal will try to interpret every one of them as a character. Most will render as nonsense. Some, though, are control characters — bytes that terminals treat as instructions rather than as things to display.

The result can be a terminal that is genuinely confused: text in the wrong colours, characters replaced by line-drawing symbols, your typing invisible. Chapter 1.3 separated the terminal from the shell, and this is a case where the terminal has been put into a strange state while the shell underneath is perfectly fine.

The fix is one command, worth remembering before you need it:

$ reset

That restores the terminal to sane defaults. If your typing is invisible, type it anyway and press Enter — it still works, you just cannot see it. clear is a different command that only blanks the screen and will not help here.

To look at a file like this safely, first ask what it is:

$ file /bin/ls
/bin/ls: ELF 64-bit LSB pie executable, x86_64, dynamically linked

file reports what a file actually contains, and it is Chapter 4.7's subject. The habit it supports: when you do not know what a file is, ask before you print it.

7. A Habit to Form Early

There is one more thing to know about cat, which you will meet properly in Module 12.

cat is very often used to feed a file into another command. That works, and there is usually a shorter and cheaper way to say the same thing, because most commands can open a file themselves. You will see both styles in other people's scripts, and the shorter one is generally preferred.

This chapter is not the place for the syntax. The reason to mention it now is so that the preference does not look arbitrary when Module 12 explains it: cat is for showing you a file, and when the destination is another program rather than your eyes, there is often a more direct route.

8. Choosing Between the Module's Commands

The whole module, previewed, so you know what is coming and when cat is genuinely right:

cat keeps its place at the top of that list. For a configuration file, a short script, a note or a small data file, it is exactly right and nothing else is simpler.

9. Why This Matters in Engineering Work

Engineering work produces two kinds of text file in quantity, and cat is correct for one and wrong for the other.

Configuration and small inputs — a few dozen lines describing how something should run. cat is the right tool: you want all of it, it fits on a screen, and you are checking it rather than searching it.

Logs — thousands to millions of lines produced by a running job. cat is the wrong tool every time, and the instinct to reach for it is the single most common beginner habit worth replacing. A log is never read whole; it is sampled at the end, searched for a word, or paged through around a point of interest. Chapters 4.2, 4.3 and 4.4 are each one of those, and Part II works with logs constantly.

The rule that generalises: small and complete, use cat. Large or unknown, ask a narrower question.

10. Practice

Question 1. What does the name cat stand for, and how does that explain what happens when you give it three files?

Question 2. cat part1.txt part2.txt prints six lines with nothing between the two files' contents. Why is there no separator, and what would you need in order to tell where one file ended?

Question 3. You run cat huge.log on a 2 GB file. Nothing is damaged, but you learn nothing. Explain precisely why, in terms of what cat does and what a terminal keeps.

Question 4. Which single command would you run before cat on an unfamiliar file, to decide whether cat is appropriate? Give two different commands and say what each tells you.

Question 5. Your terminal shows garbled characters and your typing is invisible after a command. What most likely happened, which command fixes it, and why will clear not help?

Question 6. cat -A config.txt ends every line with a $. What is that marking, and which later chapter uses it to diagnose a real failure?

Question 7. For each of these, say whether cat is the right tool and why: a 40-line configuration file; a 900 MB simulation log; a compiled program; a 12-line shell script.

11. Remember

• Module 4 only reads. Nothing in it modifies a file, so you can experiment freely.
• cat prints a file to your screen, and accepts every path form from Module 2.
• The name means concatenate. Several files are printed in order with no separator — which is why it is the command used to join files together.
• cat -n numbers lines; cat -A shows line endings, which is Chapter 4.7's main diagnostic tool.
• cat has no concept of stopping. On a large file it sends everything, your scrollback discards the beginning, and you are left with the last screenful.
• Check the size first with ls -lh. Under a few hundred lines, cat is right.
• A non-text file can leave your terminal confused. reset restores it; clear does not. Ask file before printing something unfamiliar.
• Small and complete, use cat. Large or unknown, ask a narrower question.

The next chapter answers "let me move around a long file" — a command that opens a file of any size instantly, because it never reads more than it needs to show you.