Asep Sayyad

Posted on Sep 4 Originally published at asepsayyad007.in

You’re Probably Using cat Wrong: Here’s What I Use Instead

#linux #ubuntu #devops #tutorial

Why the most popular Linux command gets abused, how it hurts performance, and the modern CLI tools that replace it.

Almost every Linux user learns cat on their very first day in the terminal.

You open a shell, navigate into a directory, and need to see what is inside a file. Your fingers automatically type cat filename.txt. The contents flash across your screen, and you move on to your next task.

Over time, that initial habit hardens into an unconscious reflex. You reach for cat when you want to view a configuration file. You reach for cat when you need to inspect a Docker log. You type cat file.txt | grep error without giving it a second thought. You use it to browse source code, peek at server metrics, and pipe data between commands.

I did the exact same thing for years. It felt natural, quick, and harmless.

Then I started managing production environments with multi-gigabyte log streams, large distributed microservices, and high-throughput pipelines. That was when I realized something important: cat is one of the most misunderstood and misused commands in the entire Unix toolkit.

Using cat as your default file viewer is not just inefficient. In many situations, it freezes your terminal, wastes CPU cycles, creates unnecessary kernel overhead, and strips away helpful context like syntax highlighting and git status.

Understanding why cat causes these problems, and knowing what to use instead, will change the way you interact with the Linux command line.

1. The Original Purpose of cat: Concatenation, Not Viewing

To understand why using cat as a daily file reader is a mistake, you have to look at what the command was built to do.

The name cat is short for catenate, which means to connect things together in a series or chain. Ken Thompson and Dennis Ritchie wrote the original version in 1971 for Version 1 Unix on the PDP-11.

The primary goal of cat was simple: take two or more files, read their byte streams in sequential order, and write them out together as a single combined stream.

Here is what proper, intended use of cat looks like:

# Glue multiple log chunks into one consolidated archive
cat morning.log afternoon.log evening.log > full-day.log

# Reassemble a split archive created by the split utility
cat backup.tar.gz.part* > backup.tar.gz

# Combine a header, body template, and footer into a final document
cat header.txt body.txt footer.txt > final_report.txt

In every single one of those examples, cat does exactly what its name promises. It takes multiple inputs and concatenates them into one destination stream.

So how did it become the default command for reading a single file?

In Unix, standard output (stdout) points to the terminal screen by default. If you run cat with only one file argument and do not redirect the output to another file, the command simply reads those bytes and pushes them directly to your screen.

It worked, so early Unix users adopted it as a quick shortcut. Over decades, tutorials and books passed down that shortcut to generations of new administrators. But printing a single file to a terminal screen was never the reason cat was written. It was merely a convenient side effect of Unix stream design.

When you use a tool designed for stream concatenation as an interactive document viewer, you quickly run into severe limitations.

2. The "Useless Use of Cat" (UUOC) and Kernel Overhead

The most common mistake people make with cat is using it to feed data into another command through a pipe.

You see this pattern everywhere in production shell scripts, tutorials, and daily terminal habits:

# Common anti-patterns
cat access.log | grep "500 Internal Server Error"
cat inventory.csv | awk -F',' '{print $1, $3}'
cat config.json | jq '.database.host'
cat users.txt | wc -l
cat payload.xml | sed 's/http:/https:/g'
cat system.log | cut -d' ' -f5 | sort | uniq -c

This pattern is so pervasive that in the mid-1990s, Usenet shell programmer Randal L. Schwartz coined the term Useless Use of Cat (UUOC). For years, senior Unix administrators awarded tongue-in-cheek "UUOC Awards" to scripts that piped cat into commands that could already read files directly.

Why does this matter? Is it just pedantic style critique, or does it truly impact your system?

To see why UUOC is bad engineering, look at what the Linux kernel must do behind the scenes when you run a pipeline like cat access.log | grep "error".

# The inefficient pipe
cat access.log | grep "error"

# The clean, direct alternative
grep "error" access.log

When you type cat access.log | grep "error", your shell performs the following sequence of operations:

Kernel Pipe Creation: The shell executes the pipe() system call. The kernel allocates a dedicated inter-process communication (IPC) circular buffer in kernel memory, which defaults to 64 kilobytes on modern Linux systems.
Process Forking: The shell invokes fork() (or clone()) twice. It spawns two completely separate child processes: one for the cat binary and one for the grep binary.
File Descriptor Duplication: The shell calls dup2() multiple times. It wires the standard output of the cat process to the write end of the pipe, and wires the standard input of the grep process to the read end of the pipe.
Binary Execution: The shell runs execve() to load and execute /usr/bin/cat, and runs another execve() to load and execute /usr/bin/grep.
Memory Copying and Context Switching: The cat process issues read() system calls to fetch chunks from the storage drive into its own user-space memory buffer. Then it issues write() calls to copy that data into the kernel pipe buffer. Meanwhile, the operating system scheduler repeatedly pauses and resumes execution, performing CPU context switches between the cat process and the grep process. Finally, grep issues its own read() system calls to pull data from the pipe buffer into its user space.

Now compare that entire cascade of operations with the direct command:

grep "error" access.log

In the direct version, the shell spawns exactly one process (grep). The kernel creates zero pipes. There is zero inter-process context switching. The grep binary opens access.log directly via the openat() system call and reads the file into memory using fast, sequential page-aligned reads.

If a command accepts a file path as an argument, passing the file directly is always faster, cleaner, and less taxing on system resources.

What if a command does not accept a file path, such as tr or certain custom binaries? You still do not need cat. Use standard shell input redirection instead:

# Avoid this:
cat raw_names.txt | tr 'a-z' 'A-Z'

# Do this instead:
tr 'a-z' 'A-Z' < raw_names.txt

Using < raw_names.txt instructs the shell itself to open the file descriptor and bind it to standard input before executing tr. You get zero extra child processes and zero pipe overhead.

3. Production Danger: The Terminal Screen Freeze

Beyond process overhead, running cat on single files in production can cause real operational headaches.

Imagine you are SSHed into a busy production server that is experiencing an alert. You change into /var/log and want to inspect what just happened. Without thinking, you type:

cat /var/log/nginx/access.log

If that log file is ten gigabytes, you just initiated a small disaster for your local terminal session.

cat does not care how large the file is. It has no internal rate limiting and no awareness of your screen size. It immediately reads every single byte from disk as fast as the NVMe drive can push it and dumps it straight into your standard output stream.

Here is what happens next:

Pseudo-Terminal Buffer Congestion: Thousands of lines per second flood into your pseudo-terminal device (/dev/pts/*). Your terminal emulator (such as Windows Terminal, iTerm2, Alacritty, or Kitty) must parse ANSI sequences, calculate word wraps, render glyphs, and update graphics memory. The terminal application will frequently freeze or stutter.
Network Saturation: If you are connected over an SSH session, the server tries to push gigabytes of raw text across your TCP connection. The SSH TCP window fills up, your latency skyrockets, and your keystrokes stop responding.
The Ctrl+C Delay: You desperately press Ctrl + C to send a SIGINT signal. While cat might terminate on the remote host within a few hundred milliseconds, your local terminal emulator still has megabytes of text buffered in its socket receive queue. Your screen continues to flicker and scroll uncontrollably for another thirty seconds while you wait for the backlog to clear.
Lost History: The runaway stream instantly overflows your terminal scrollback buffer. Any previous diagnostic commands, error codes, or notes you had visible in your terminal window get wiped away into oblivion.

There is another common trap: accidentally running cat on a binary or compressed file.

# An easy typo with unpleasant consequences
cat application.tar.gz
cat /usr/local/bin/custom_daemon

When raw binary data dumps into a terminal emulator, unprintable byte sequences get interpreted as hardware control characters. These escape codes can alter your terminal character set, turn all future typed text into unreadable Greek or graphic runes, disable cursor visibility, and break your prompt formatting.

When that happens, you have to run reset or stty sane blindly to recover your shell session:

# The recovery commands when cat corrupts your terminal
reset
stty sane

A tool that can freeze your session or corrupt your display with a single typo is not the right tool for inspecting files.

Here is what you should use instead.

4. What to Use for Code, Configs, and Scripts: bat

If you want a modern, drop-in replacement for viewing source code, configuration files, and shell scripts on your local workstation or bastion host, the best tool available today is bat.

Written in Rust, bat describes itself as "a cat clone with wings." It does everything you wish cat did when browsing files.

Here is what makes bat exceptional:

Syntax Highlighting: It automatically detects hundreds of programming languages, configuration formats, and markup types (JSON, YAML, TOML, Python, Go, Bash, Rust, Dockerfiles, Nginx configurations). Code displays with clear, legible color themes instead of monochrome walls of text.
Git Integration: It queries Git in the current repository. If lines have been added, removed, or changed since the last commit, bat places colored indicators in the left gutter (+, -, ~). You see your working tree changes instantly without running a separate diff command.
Automatic Smart Paging: If the file fits entirely on your current terminal screen, bat prints it and exits immediately, exactly like cat. If the file is longer than your screen height, bat automatically routes the output through an interactive pager (like less), allowing you to scroll, jump, and search without flooding your history.
Line Numbering: It prints clean, non-intrusive line numbers by default, making it easy to discuss specific lines during debugging sessions.
Non-Printable Character Inspection: With the -A flag, bat highlights invisible spaces, tabs, and carriage return characters (\r) that often break shell scripts copied from Windows environments.

Let us look at common ways to use bat:

# View a configuration file with full syntax highlighting and line numbers
bat /etc/nginx/sites-available/api.conf

# View only a specific range of lines (e.g., lines 45 through 70)
bat -r 45:70 deploy.sh

# Plain mode: strip line numbers and decorations when copying with your mouse
bat -p config.yaml

# Highlight git modifications compared to HEAD
bat src/controllers/auth.py

# Reveal hidden whitespace and carriage returns
bat -A startup.sh

How to Install bat

On Ubuntu and Debian systems:

sudo apt update
sudo apt install bat

On Debian and Ubuntu, the package installs the binary as batcat to avoid a naming conflict with another legacy utility. You can set up an alias in your ~/.bashrc or ~/.zshrc file to use bat naturally:

# Add this to your ~/.bashrc
alias bat='batcat'

On Fedora, CentOS, and RHEL:

sudo dnf install bat

On Arch Linux:

sudo pacman -S bat

On macOS using Homebrew:

brew install bat

Once you get used to syntax-highlighted configurations and automatic paging, running plain cat on code feels like going back to black-and-white television.

5. What to Use for Large Files and Logs: less

When you are working on a remote production server where third-party packages like bat are not installed, your default tool for viewing files should almost always be less.

less is pre-installed on virtually every Linux distribution in the world. It is the opposite of more (an older, more primitive pager), which inspired the classic Unix saying: "less is more, but more than more is less."

The core engineering advantage of less is how it handles memory and storage I/O.

When you run cat large_file.log, the entire file must be read and transmitted. When you run less large_file.log, the program opens the file descriptor, seeks to the beginning, reads only the tiny byte range required to fill your visible terminal screen (typically 4 to 8 kilobytes), and stops.

It does not matter whether the file is 500 megabytes or 50 gigabytes. less opens in a fraction of a millisecond with near-zero memory consumption.

Essential less Flags for Production

Running bare less is good, but running it with the right flags makes it vastly more capable:

-N: Prints line numbers along the left margin.
-S: Chops long lines instead of wrapping them. This is critical for reading dense application logs. Instead of a single 400-character JSON payload wrapping across eight messy screen lines, it stays on one neat horizontal line. You can scroll left and right using the arrow keys to read the rest.
-R: Preserves raw ANSI color escape sequences. If an application outputs colored log messages (green for INFO, red for ERROR), less -R renders the colors accurately rather than printing garbled escape codes like \033[31m.
-F: Causes less to exit automatically if the entire file fits on one screen. This gives you the exact convenience of cat for small files while keeping you protected on large ones.
-X: Prevents less from clearing the terminal screen when you quit. This leaves whatever you were inspecting visible in your prompt buffer so you can reference it while typing subsequent commands.

You can combine these into a single command:

less -NSRFX /var/log/syslog

If you do not want to type those flags every time, define the LESS environment variable in your shell profile:

# Add this to your ~/.bashrc or ~/.bash_profile
export LESS="-R -S -F -X"

Once set, typing less filename.log automatically applies your preferred viewing flags.

Navigation Commands Inside less

Many engineers only know how to scroll up and down using arrow keys in less. The real power comes from its built-in navigation shortcuts:

G: Jump straight to the end of the file.
1G or g: Jump to the very beginning of the file.
/pattern: Search forward for a regex pattern. Press n to jump to the next occurrence, or N to jump backward.
?pattern: Search backward from your current position.
F: Enter Follow Mode. This makes less behave exactly like tail -f. It waits for new log lines to be appended and scrolls live.
Ctrl + C: Interrupt Follow Mode. Unlike tail -f, where stopping the stream kills the process and dumps you back to the shell prompt, interrupting Follow Mode in less keeps you right inside the file! You can immediately press ? or / to search backward through the errors that just occurred. Press F again whenever you want to resume live streaming.

That single feature (switching seamlessly between live streaming and interactive log searching without restarting commands) makes less superior to cat and tail combined.

6. What to Use for Quick Previews: head, tail, and sed

Sometimes you do not need an interactive pager. You just need a quick glimpse to verify a file's structure, check a header row, or inspect the most recent crash trace.

Using cat for this is lazy and risky. Use dedicated boundary inspection tools instead.

Inspecting Headers with head

When dealing with large CSV files, data dumps, or configuration templates, you usually only care about the first few lines:

# View the first 10 lines (default)
head users_export.csv

# View specifically the first 25 lines
head -n 25 /var/log/boot.log

# Check the header of multiple files simultaneously
head -n 5 *.conf

head reads the requested number of newline characters and terminates immediately, closing the file descriptor without wasting CPU time on the rest of the file.

Inspecting Recents with tail

To see what recently happened on a system, look at the end of the file:

# View the last 40 lines of an error log
tail -n 40 /var/log/nginx/error.log

# Follow live updates
tail -f /var/log/auth.log

# Follow live updates with auto-reopen on log rotation
tail -F /var/log/application.log

Notice the uppercase -F flag. If your server runs logrotate, a standard tail -f command holds an open file descriptor to the old, renamed file (application.log.1) and stops receiving new events when the file rotates. The -F flag tracks the file by filename rather than inode number. If the file gets renamed and a new empty file is created in its place, tail -F automatically reopens the new file and continues streaming.

Slicing a Range with sed

What if you know an error occurred between line 450 and line 485 of an application file? You do not need to open an editor or scroll through thousands of lines. Use sed to slice the exact window:

# Print only lines 450 through 485 and exit
sed -n '450,485p' /var/log/application.log

The -n flag suppresses default printing, and 450,485p tells the stream editor to print only that specific range. It is fast, clean, and pipe-friendly.

7. What to Use for Chronological Logs: tac

Here is a command that many Linux administrators go years without discovering: tac.

tac is literally cat spelled backwards. Its behavior matches its name: it reads files from the bottom up, printing the lines in reverse order.

Why does this matter?

In almost every modern operating system and application, logs are written chronologically. The oldest entries sit at the very top of the file, and the newest events land at the very bottom.

When you run cat or grep on a multi-gigabyte log file to find a recent issue, the command starts reading from the first line recorded last Monday morning. It spends minutes chewing through old, irrelevant data before reaching today's incidents.

With tac, you start from the newest events and move backward in time:

# Search for the 5 most recent out-of-memory errors
tac /var/log/kern.log | grep -m 5 "Out of memory"

# Inspect the most recent authentication failures
tac /var/log/auth.log | grep -m 3 "Failed password"

The -m 5 flag tells grep to exit immediately after finding five matches. Because tac feeds the data starting from the very end of the file, grep finds the five most recent occurrences within milliseconds and exits. The kernel stops processing the rest of the multi-gigabyte file.

Using tac instead of cat for log triage can turn a two-minute search into a split-second query.

8. What to Use for Compressed Logs: zcat, zless, and zgrep

On any production Linux server, log maintenance daemons compress older log files using gzip to preserve disk capacity. Your log directory typically looks like this:

/var/log/syslog
/var/log/syslog.1
/var/log/syslog.2.gz
/var/log/syslog.3.gz
/var/log/syslog.4.gz

If you need to investigate an issue that happened three days ago, running cat syslog.2.gz will dump raw binary compression streams into your terminal, corrupting your character display.

Many junior engineers respond by manually decompressing the file:

# The slow, messy approach
gunzip /var/log/syslog.2.gz
cat /var/log/syslog.2 | grep "kernel crash"
gzip /var/log/syslog.2

This workflow is slow, modifies the file timestamps, risks running out of disk space on full partitions, and requires write permissions in system directories.

Linux provides dedicated utilities designed to inspect compressed files directly in memory without modifying the compressed file on disk:

zcat: Decompresses gzip streams on the fly and pipes them to stdout.
zless: Opens a gzipped file directly in an interactive less pager with full search and scrolling.
zgrep: Runs regex searches across gzipped text without touching disk storage.

# Read a compressed log interactively
zless /var/log/nginx/access.log.2.gz

# Search across all compressed and uncompressed logs at once
zgrep "database timeout" /var/log/syslog*

If your distribution uses newer compression algorithms like bzip2, xz, or zstandard, matching tools exist:

For .bz2 files: bzcat, bzless, bzgrep
For .xz files: xzcat, xzless, xzgrep
For .zst files: zstdcat, zstdless, zstdgrep

Never uncompress an archive on disk just to read a few lines of text.

9. What to Use for Markdown and Documentation: glow

Developers and DevOps engineers spend significant time working with Markdown files: README.md files, Kubernetes architecture runbooks, API guides, and incident documentation.

When you run cat README.md, you get raw markdown markup. Headers display as #, links show as raw URLs inside brackets and parentheses, code blocks blend into surrounding text, and bullet lists look flat.

If you want to read documentation inside your terminal the way it was meant to be read, look at glow.

glow is an open-source terminal Markdown reader developed by Charm. It parses Markdown files and renders them in your terminal with rich formatting:

Headers appear in bold, distinct typography with tasteful spacing.
Code blocks display with borders and language-specific syntax highlighting.
Hyperlinks become clickable terminal links.
Blockquotes and callout alerts format with colored left accent bars.
Tables render with clean Unicode borders.

# Render a local markdown file cleanly in your terminal
glow README.md

# Page through long documentation interactively
glow -p architecture-notes.md

# Fetch and render documentation directly from a GitHub repository
glow https://github.com/torvalds/linux/blob/master/README

Using glow turns raw markdown text into readable terminal documentation.

10. What to Use for Safe Writing and Appending: tee

cat is also commonly misused for writing small files or configuration stubs using "here documents" (cat << EOF).

While cat << EOF works fine for simple unprivileged files, it breaks down the moment you need superuser privileges to write to a protected path.

Consider this common failure:

# This will fail with "Permission denied"
sudo cat << EOF > /etc/systemd/system/app.service
[Unit]
Description=My Application
After=network.target

[Service]
ExecStart=/usr/local/bin/app

[Install]
WantedBy=multi-user.target
EOF

Why does this fail even though you typed sudo?

Because the shell performs file redirection (> /etc/systemd/system/app.service) before executing the command. Your current, unprivileged shell attempts to open the destination file for writing, receives a permission denied error from the kernel, and halts execution before sudo or cat ever launch.

The reliable way to write or append to privileged files is tee.

tee reads from standard input and writes simultaneously to standard output and any number of destination files. When combined with sudo, the tee process runs with elevated privileges, allowing it to open and write to restricted files safely.

# Writing a privileged file cleanly
sudo tee /etc/systemd/system/app.service << 'EOF' > /dev/null
[Unit]
Description=My Application
After=network.target

[Service]
ExecStart=/usr/local/bin/app

[Install]
WantedBy=multi-user.target
EOF

Adding > /dev/null at the end suppresses printing the contents to standard output, keeping your terminal clean.

If you need to append a line to an existing configuration without opening an editor, use tee -a:

# Append a custom DNS resolver cleanly with elevated privileges
echo "nameserver 1.1.1.1" | sudo tee -a /etc/resolv.conf > /dev/null

tee provides clear, secure privilege separation that redirection with cat cannot match.

11. Quick Reference: Choosing the Right Tool

To replace the cat reflex in your daily routine, use this practical mental guide:

Task: Viewing source code, YAML configs, and shell scripts
- Recommended Tool: bat
- Why: Provides automatic syntax highlighting, Git change indicators, line numbers, and smart paging.
Task: Reading large logs, system diagnostics, and long files
- Recommended Tool: less -NSRFX
- Why: Reads minimal byte blocks without memory bloat, avoids terminal freezes, and supports instant regex searching and live following.
Task: Piping data into another command (grep, awk, jq, wc)
- Recommended Tool: Direct file arguments (e.g., grep "pattern" file) or input redirection (cmd < file)
- Why: Eliminates redundant processes, avoids kernel pipe buffers, and removes context-switching overhead.
Task: Quick preview of file headers or row formats
- Recommended Tool: head -n 20
- Why: Reads the first few lines and terminates immediately without reading the rest of the file.
Task: Monitoring recent application errors or live output
- Recommended Tool: tail -n 50 or tail -F
- Why: Inspects the bottom of the file directly and seamlessly tracks log rotations.
Task: Investigating chronologically ordered logs from newest to oldest
- Recommended Tool: tac
- Why: Reverses line order so searches hit recent events first.
Task: Inspecting compressed historical archives (.gz, .bz2, .xz)
- Recommended Tool: zless, zcat, or zgrep
- Why: Reads compressed streams directly in memory without disk decompression.
Task: Reading Markdown runbooks and README files
- Recommended Tool: glow
- Why: Renders clean headings, code formatting, and hyperlinks in the terminal.
Task: Writing or appending to root-owned system files
- Recommended Tool: sudo tee or sudo tee -a
- Why: Handles privilege escalation cleanly across redirects.
Task: Combining multiple files into one destination stream
- Recommended Tool: cat file1 file2 > combined
- Why: This is what cat was built to do!

Interesting Fact

In the late 1990s, the "Useless Use of Cat" (UUOC) award became so well known across the Unix community that software engineers began actively writing shell linters to catch it automatically.

Today, if you run the popular static analysis tool ShellCheck on a bash script containing cat file | grep pattern, ShellCheck triggers diagnostic code SC2002: "Useless use of cat. Consider cmd < file | .. or cmd file instead."

What started as an informal Usenet joke by Randal Schwartz over thirty years ago is now permanently hardcoded into the automated testing suites that audit enterprise infrastructure code worldwide.

Conclusion

Using cat to read files is a habit almost every engineer picks up early on. It feels convenient, and for a five-line test file on a local computer, it gets the job done.

Real command line proficiency is about understanding what tools are doing beneath the surface.

When you replace cat file | grep with direct arguments, you eliminate wasteful kernel pipelines. When you inspect logs with less instead of dumping them with cat, you protect your terminal sessions from sudden freezes and lost scrollbacks. And when you view code with modern utilities like bat or inspect markdown with glow, you get helpful visual context that saves time.

Save cat for its true calling: concatenating multiple files into one. For everything else, reach for the tool designed for the job.

Question to Reader

Do you still catch yourself typing cat file | grep out of pure muscle memory, or which modern CLI utility has completely replaced cat in your terminal workflow?

About the Author

Asep Sayyad is a Linux and DevOps engineer passionate about Linux administration, automation, cloud technologies, containers, and open-source software. He enjoys solving real-world infrastructure challenges and sharing practical knowledge through in-depth technical articles, tutorials, and hands-on guides.

His goal is to help aspiring and experienced engineers build stronger Linux and DevOps skills with content focused on real production scenarios rather than theory alone.

Connect with Me

Portfolio: asepsayyad007.in
Blog: asepsayyad007.in/blogs
GitHub: github.com/asepsayyad007
LinkedIn: linkedin.com/in/asepsayyad
Medium: asepsayyad007.medium.com

Enjoyed this article?

If you found this guide helpful, consider:

Starring my open-source projects on GitHub.
Sharing this article with fellow Linux and DevOps engineers.

You can also follow me for more practical content on Linux, DevOps, Cloud, Containers, Automation, and Open Source. Thanks for reading, and enjoy your learning!

DEV Community