Viewing Files and Redirection

You can now create, edit, move, and delete files. Sometimes, though, you don’t want to edit a file at all — you just want to see what’s in it, quickly, without opening an editor. This chapter covers the tools for that, plus something that changes how you think about commands entirely: redirecting where their output actually goes.

Dumping A Whole File: cat

cat (short for “concatenate”) prints a file’s entire contents straight to your terminal.

cat notes.txt

For a short file, this is the fastest way to see what’s inside. For a long one, everything scrolls past faster than you can read it, and you’re left looking at only the last screen’s worth. cat doesn’t paginate — it just dumps everything and stops.

cat also does something less obvious that’s genuinely useful: given multiple files, it prints them one after another, effectively joining them.

cat part1.txt part2.txt

This prints part1.txt followed immediately by part2.txt, as if they were one file — which is exactly what “concatenate” means, and where cat gets its name.

Paged Viewing: less

For anything longer than a screenful, less is the better tool. It loads a file one page at a time, letting you move through it deliberately instead of watching it fly past.

less notes.txt

Once inside, a few keys do most of the work:

Just The Start Or End: head And tail

Sometimes you don’t want the whole file — just a glimpse. head shows the first lines of a file, tail shows the last:

head notes.txt
tail notes.txt

Both default to 10 lines. Change that with -n:

tail -n 20 notes.txt

tail has one more trick worth knowing now, even though you won’t use it heavily until the Services & Boot section: -f (“follow”) keeps the file open and prints new lines as they’re added, instead of exiting immediately. This is the standard way to watch a log file in real time as a program writes to it — you’ll come back to this once we cover where those logs actually live.

tail -f /var/log/some-log-file

Ctrl+C stops following and returns you to your prompt — this is the first time you’ve needed to interrupt a running command rather than let it finish on its own.

Finding A Command’s Location: which

You’ve been running commands like ls and cat without ever asking where they actually live on disk. which answers that:

which cat

This prints the full path to the program the shell will run when you type cat — typically /usr/bin/cat. It’s mostly useful for two situations: confirming a command exists at all before you rely on it in a script, or figuring out which version of a command is about to run when more than one might be installed in different locations.

Redirecting Output: > And >>

Every command you’ve run so far has printed its output straight to your terminal. That’s actually just the default destination — not the only one. The shell lets you redirect a command’s output somewhere else entirely, most commonly into a file.

ls -l /etc > listing.txt

Instead of appearing on screen, the output of ls -l /etc is written into listing.txt. If listing.txt already exists, > overwrites it completely — the previous contents are gone, the same way cp and mv overwrite silently.

If you want to add to a file instead of replacing it, use >>:

echo "one more line" >> listing.txt

>> appends to the end of the file, creating it first if it doesn’t already exist. The difference between > and >> is one character and an entirely different outcome — worth double-checking before you run either against a file you care about.

There’s a matching operator for the opposite direction: < feeds a file in as a command’s input instead of having the command open the file itself. You won’t use it often this early, but you’ll see it in other people’s scripts.

Redirecting Error: 2>

> redirects a command’s normal output — but errors are a separate stream entirely. Try redirecting a command that fails, and the error message shows up on screen anyway, even though you redirected it:

ls /no-such-directory > listing.txt

Run that, and listing.txt ends up empty, while the error still prints to your terminal. That’s because Linux commands actually have two separate output streams: standard output (stdout, everyday results) and standard error (stderr, error messages), and > only redirects the first one.

Each stream has a number, called a file descriptor: 1 for stdout, 2 for stderr. > on its own is really shorthand for 1>. To redirect errors specifically, write the 2 explicitly:

ls /no-such-directory 2> errors.txt

Now the error message lands in errors.txt instead of your screen. 2>> appends to an error file the same way >> appends to a normal one.

Redirecting Output And Error Into Same File &>

Sometimes you want both streams captured together — everything a command produces, success or failure, in one place. Writing 2>&1 after a normal redirect does this:

some-command > combined.txt 2>&1

The order here isn’t cosmetic — it matters. > combined.txt first points stdout at the file. 2>&1 then says “make stderr go wherever stdout is currently going,” which is now that same file. Reverse the order — 2>&1 > combined.txt — and it does something different: stderr gets pointed at wherever stdout was going at that moment (your terminal), and only afterward does stdout get redirected to the file, leaving errors still printing to your screen.

About /dev/null

Occasionally you don’t want a stream captured anywhere at all — you just want it gone. /dev/null is a special file, mentioned briefly back in the Filesystem Hierarchy Standard file, that discards anything written to it. Nothing is stored; there’s nothing to clean up afterward.

some-command 2> /dev/null

This runs a command normally but silently discards any error output, useful when a command is known to produce harmless warnings you don’t want cluttering your screen or a log file. Combine it with &> to discard everything:

some-command &> /dev/null

Chaining Commands: Pipes

Redirection sends output to a file. A pipe, written |, sends the output of one command directly into the input of another — no file involved at all.

ls -l /etc | less

This runs ls -l /etc, but instead of dumping potentially hundreds of lines straight to your screen, feeds that output into less, letting you page through a long directory listing the same way you’d page through a file.

    flowchart LR
    A["ls -l /etc"] -->|"output becomes input"| B["less"]
    B --> C["Paged view on screen"]
  

This is one of the most important ideas in this entire course, even though it looks small: Linux commands are designed to be combined. ls doesn’t know or care that its output is going into less instead of your screen — it just produces output the same way it always does, and the pipe handles getting it where it needs to go. Once grep is in your toolkit in the next chapter, piping into it becomes one of the most common things you’ll do on a daily basis.

What’s Next

You can now view files without editing them, and you understand the difference between a command’s output going to your screen, into a file, or into another command. Neither cat nor less can search inside file contents for a specific pattern, though — that’s a big enough topic on its own to earn its own chapter, coming up next: grep.