Step 19. Linux Basic Commands 2 — Three Pipes for Steering Output

Level 0 — Understanding Computer Operation and Structure | Difficulty ★★★☆☆ | Estimated time: 3 hours

Prerequisites: Step 18 complete. Work in the Ubuntu terminal inside your virtual machine.

What you need: the Ubuntu virtual machine, an environment where you can open two terminals (used in Section 3-5).
Caution: today’s exercise is 100% safe because it’s inside the VM. ⚠️ There is one single warning — > erases a file’s existing contents and writes over them. Nail this one down and move on.
Hands-on note: the outputs in this chapter are real results run on Ubuntu 24.04. The verification was done with the administrator (root) account, so paths show /root, but on your VirtualBox Ubuntu you’ll see /home/username. Other than that difference, everything is the same.

Think of the machines in a factory. Each machine has a pipe where water comes in and a pipe where it goes out. If a plumber pulls out the outflow pipe and plugs it into another machine’s inlet instead of the drain, you get a production line of two connected machines. Linux commands are exactly these machines. You reroute output that was heading for the screen into a file (>), or into another command’s input (|). This plumbing skill is the real power of Linux commands. Keep Step 3’s pipes and Step 4’s Out-File in mind — different names, same idea.

1. Learning Objectives

By the end of this chapter, you will be able to:

Explain the three standard streams (stdin/stdout/stderr) along with their numbers
Choose among cat, less, head, and tail based on a file’s length and your purpose
Explain the difference between > and >> (overwrite vs. append) and use them correctly
Connect two commands with a pipe (|) to shape the result
Experience real-time log monitoring with tail -f and stop it with Ctrl + C

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category	Details
Language/Environment	Ubuntu Linux terminal (bash)
Today’s commands	`cat` / `less` / `head` / `tail` (viewing files), `echo` (making output), `wc -l` (counting lines), `>` `>>` `
Concepts needed	standard streams (pipes 0, 1, 2), redirection, pipes, overwrite vs. append

2-1. Standard Streams — stdin, stdout, stderr

Every Linux command comes with three pipes — standard streams — connected by default:

Name	Number	Role	Default connection
stdin (standard input)	0	what comes in	keyboard
stdout (standard output)	1	normal results	screen
stderr (standard error)	2	error messages	screen

The key insight: "normal results" and "errors" flow through different pipes. You just couldn’t tell them apart because both end up on the screen. Why this distinction matters becomes real in Step 20 — there’s a technique for sending only the error pipe (number 2) into the trash.

2-2. Redirection — Changing a Pipe’s Direction

We said output goes to the screen by default. Changing that direction is redirection:

command > file — send output to a file (existing content is deleted and rewritten)
command >> file — append output to the end of a file

When you learned PowerShell’s Out-File -Append in Step 5, we said "records aren’t overwritten, they’re accumulated." In Linux, > and >> play that role. And today’s warning: the difference between one (>) and two (>>) is "erase and write" vs. "continue writing" — everyone has a beginner-era accident where this one-character difference wipes out a precious file. Have that accident safely today.

2-3. Pipes — From Command to Command

| is a pipe connecting "the left command’s output" to "the right command’s input." It’s exactly the concept you learned with PowerShell in Step 3, and in fact Linux (Unix, to be precise) is where the idea originated. It’s the core component of the philosophy of "assembling small tools."

2-4. Four Tools for Viewing Files — Why Four?

Tool	Character	When to use
`cat`	dumps everything at once	short files
`less`	one screen at a time, navigate back and forth	long files
`head`	only the beginning	checking the first few lines
`tail`	only the end	the latest log entries

Log files get newer toward the end. That’s why tail is what security analysts use most — "what happened recently?" always lives at the back of the file.

3. Follow Along

3-1. Trying the Viewing Tools — cat, head, tail

Let’s practice with a file already on the system. /etc/passwd is a file containing the list of user accounts:

cat /etc/passwd

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
...
tcpdump:x:105:110::/nonexistent:/usr/sbin/nologin

(Verified 2026-09-09 — in the verification environment, the whole 29-line file was printed. Your VM will be a bit longer because of the account line created during installation.)

How to read it: each line is one account, in the form name:x:number:number:description:home_directory:default_shell. The screen scrolls by — thankfully it’s a short file. Now, a tool for traveling through long files:

less /etc/passwd

A different world opens: only one screenful is shown; spacebar for the next page, ↑↓ to move line by line, press / and type to search, and q to quit. less is "a tool for traveling inside a file." Press q to exit.

head -n 5 /etc/passwd

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync

tail -n 5 /etc/passwd

uuidd:x:103:103::/run/uuidd:/usr/sbin/nologin
landscape:x:104:105::/var/lib/landscape:/usr/sbin/nologin
polkitd:x:990:990:User for polkitd:/:/usr/sbin/nologin
dnsmasq:x:999:65534:dnsmasq:/var/lib/misc:/usr/sbin/nologin
tcpdump:x:105:110::/nonexistent:/usr/sbin/nologin

(Verified 2026-09-09.)

How to read the output: just the first 5 lines and the last 5 lines. -n 5 is the option for "5 lines." It’s the fastest way to check "what does this look like?" when a file is very long.

Why do it: with small files it feels underwhelming, but when you later meet a log of hundreds of thousands of lines, cat will flood the screen and freeze the terminal. That’s when "ah, that’s why less and tail exist" hits you.

3-2. Create, Overwrite, Append — > vs >>

Let’s work in a practice directory (cd ~, then mkdir stream-lab; cd stream-lab):

echo "hello" > a.txt
cat a.txt

hello

echo is a command that "prints the text it’s given as-is." The > rerouted that output to a file instead of the screen. Now today’s cautionary experiment:

echo "world" > a.txt
cat a.txt

world

(Verified 2026-09-09.)

Did you predict it? hello is gone and only world remains. > overwrites — it silently erases the existing content. Now appending:

echo "hello again" >> a.txt
cat a.txt

world
hello again

(Verified 2026-09-09.)

>> appends to the end. This difference is today’s core: every time you save, ask yourself once, "Is > okay in this situation?" If you’re accumulating a log, use >>; if you’re intentionally rewriting, use >.

3-3. Pipes — Combining Commands

ls /etc | wc -l

(Verified 2026-09-09. The number differs by environment — different installed components mean different counts.)

How to read it: the output of ls /etc (the file list) never appeared on screen — it flowed into the input of wc -l. wc is word count — with the -l option it counts lines. Result: "there are 180 entries under /etc."

Remember Step 5? It’s exactly the same pattern as Get-Service | Measure-Object. Make a list → count it. The tools change; the way of thinking stays one.

3-4. Save and Verify — A Field Routine

ls -la /etc > filelist.txt
head -n 3 filelist.txt

total 864
drwxr-xr-x 100 root root       4096 Sep  9 11:29 .
drwxr-xr-x  22 root root       4096 Sep  9 11:28 ..

(Verified 2026-09-09.)

The shape of the routine: create (>) → verify (head/cat). Always verify right after saving — this two-second habit prevents the "I thought I saved it, but it’s an empty file" accident.

Why reroute output to files: this small technique is the threshold of automation. Being able to leave a command’s results in a file means — ① records: you can later compare "what was there back then" (the baseline from Step 15!), ② handoff: you can pass results to another program or person, ③ overnight work: you can read in the morning the results of commands that ran while you slept. If Step 9’s scripts were "commands that survive after the window closes," redirection is "results that survive after they finish."

3-5. Real-Time Monitoring — tail -f

Today’s highlight. Open two terminal windows (File menu → new window, or Ctrl + Alt + T twice).

In window 1:

touch live.log
tail -f live.log

Nothing happens and the cursor just blinks — this command doesn’t finish. tail -f means "keep watching the end of the file" (follow). When a new line is added to the file, it appears on screen immediately.

In window 2:

echo "first event" >> ~/stream-lab/live.log
echo "second event" >> ~/stream-lab/live.log

Look at window 1 — those lines just appeared in real time:

first event
second event

(Verified 2026-09-09 — this is actual screen output from running the same principle.)

To stop, press Ctrl + C in window 1.

Make a prediction: what would tail -f look like on a server where dozens of log lines pile up every second? (Answer: the screen scrolls relentlessly. That’s why in the field you attach a filter with a pipe, like tail -f log | grep ERROR, to see only what you want — a combination of today’s two techniques, and the principle behind a security operations center’s screens.)

Why this matters for security: security monitoring starts from "watching logs in real time." Seeing with your own eyes the moment a sign of attack (a burst of failed logins, for instance) lands in the log — today you ran a miniature version of that watchtower yourself.

4. Missions & Exercises

Mission — Your Own Observation Journal

Create a watch-log.txt file and record five of the commands you practiced today, appending one line at a time with echo and >> (e.g., echo "1. ls /etc | wc -l → 180 entries" >> watch-log.txt)
Use >> every time so five lines accumulate (if even one line uses >, the earlier ones get erased — that’s the test)
Do a final check with cat watch-log.txt
Finally, run ls /etc | tail -n 3 and explain out loud why tail comes after the pipe

How to verify yourself: you pass if the final file has all five lines. If a middle line disappeared, look back at where you used > — that’s how today’s warning gets etched into your muscle memory.

Exercises

Question 1. Explain the difference between > and >> from the perspective of "the fate of existing content," and say which one you should use when accumulating a log file.

Question 2. State the numbers and roles of the three standard streams, and give one example of why the fact that "normal results and errors flow through different pipes" is useful.

Question 3. Explain the execution of ls /etc | wc -l using the phrase "the left side’s output → the right side’s input."

Question 4. Why doesn’t tail -f finish on its own, and how do you stop it? And why is this command used in security monitoring?

5. Model Answers & Completion Criteria

Mission Model Answer

cd ~/stream-lab
echo "1. cat /etc/passwd — view the whole accounts file" >> watch-log.txt
echo "2. head -n 5 /etc/passwd — just the first 5 lines" >> watch-log.txt
echo "3. ls /etc | wc -l — count entries in /etc (180 verified)" >> watch-log.txt
echo "4. echo ... >> a.txt — appending" >> watch-log.txt
echo "5. tail -f live.log — real-time monitoring (exit with Ctrl+C)" >> watch-log.txt
cat watch-log.txt

1. cat /etc/passwd — view the whole accounts file
2. head -n 5 /etc/passwd — just the first 5 lines
3. ls /etc | wc -l — count entries in /etc (180 verified)
4. echo ... >> a.txt — appending
5. tail -f live.log — real-time monitoring (exit with Ctrl+C)

How to verify: ① Does cat show five lines? ② Did the lines accumulate in the order they were appended? ③ For reference, both > and >> create the target file if it doesn’t exist, so starting the first line with >> still creates the file. ④ Sample explanation for ls /etc | tail -n 3: "to avoid dumping the whole list on screen — pipe it into tail to see only the last 3 lines" (verified output: xdg, xml, zsh_command_not_found — may differ in your environment).

Exercise Answers

Answer 1. > erases existing content and writes new (overwrite); >> appends to the end of existing content. When accumulating records like a log, you must use >> — with >, all previous records are wiped out.

Answer 2. 0 is stdin (input, default keyboard), 1 is stdout (normal output, default screen), 2 is stderr (errors, default screen). Example of usefulness: you can discard just the error messages (pipe 2) or collect them into a file, so normal results (pipe 1) don’t get buried under errors. Step 20’s 2>/dev/null is exactly this application.

Answer 3. The output of ls /etc (the file list) doesn’t appear on screen — it flows through the pipe into the input of wc -l. Since wc -l counts the lines of its input and outputs the count, the result is "the number of entries under /etc" (180 in verification).

Answer 4. tail -f‘s job is "keep watching the end of the file," so not finishing on its own is by design. You stop it with Ctrl + C — the universal brake that "interrupts whatever is currently running." Why it’s used in security monitoring: to watch the very moment signs of an attack land in the log, in real time.

Completion Checklist

[ ] I can explain the three standard streams (input/output/error) with their numbers
[ ] I can choose among cat, less, head, and tail appropriately
[ ] I can exit less with q
[ ] I can explain the difference between > and >> and use them correctly
[ ] I can connect two commands with a pipe (ls /etc | wc -l, etc.)
[ ] I experienced real-time monitoring with tail -f and stopped it with Ctrl + C
[ ] Mission: I completed the five lines of watch-log.txt

6. Common Pitfalls & Fixes

Wall 1. I used > and the earlier content disappeared

Symptom: you definitely meant to append, but the file has only the last line.
Cause: exactly today’s warning — > overwrites.
Fix: accumulating means >>. And consider yourself lucky to have this accident now, in the practice ground. Experience it once in a VM and you’ll remember it for life.

Wall 2. I can’t get out of less

Symptom: whatever you type inside less does nothing.
Cause: less is its own world — it has its own key controls.
Fix: q is the exit. Just memorize that. (For reference: inside less, / searches and n jumps to the next match — the actual hand movements of an analyst hopping between incident scenes in a long log.)

Wall 3. tail -f never ends

Symptom: the command never completes; the cursor just blinks.
Cause: it’s not broken — it’s by design. Watching is its job, so it never ends on its own.
Fix: Ctrl + C. The common solution in the terminal for "things that won’t stop."

Wall 4. I typed a pipe but the first command’s output comes out as-is

Symptom: you typed ls /etc | wc -l but you see the list.
Cause: the | wasn’t entered properly (Korean input mode, etc.), or the order got flipped.
Fix: check your keyboard state, and read the order out loud: "the left side’s output → the right side’s input." Pipes have a direction.

Wall 5. I typed echo and the quotes or special characters came out wrong

Symptom: echo "$HOME" and similar produce unintended output.
Cause: the thing you learned in Step 7 — double quotes expand variables; single quotes take text literally. bash follows the same rule!
Fix: decide your intent and pick your quotes: " " to expand values, ' ' to write literally. It’s a fun point that this rule carries straight over from Windows to Linux.

7. Summary

Today’s Concepts

Concept	One-line description
Standard streams	Three pipes: input (0), output (1), error (2)
`>` / `>>`	Overwrite / append — remember the difference!
`	` (pipe)
`tail -f`	Watch a file’s end in real time (exit with Ctrl+C)

Today’s Commands

Command	What it does
`cat` / `less`	View all / navigate by pages (exit with q)
`head` / `tail`	Beginning / end (`-n 5` sets the line count)
`echo`	Print text (the raw material for making files)
`wc -l`	Count lines (a pipe’s favorite partner)

More Important Than Commands: The Instinct

The actual hand movements of log analysis are combinations of what you learned today: the latest entries via tail, monitoring via tail -f, collection via >>, tallying via | wc -l. And the > overwrite accident is the classic "wiping out the records" mistake — the more you handle evidence, the more sensitive you must be to this one character.

Remember two more things. First, behind today’s pipe lies 50-year-old Unix philosophy — "assemble small programs that each do one thing well to accomplish big things." grep only searches, wc only counts, tail only looks at the end — but chain them with | and "pick out only the errors from a log and count them" becomes one line. Second, when you later meet the cryptic 2>&1, decode it with today’s table — "send pipe 2 (errors) to the same place as pipe 1 (output) (&1)." Today’s three-pipe table is the decryption key to that code.

Once every box is checked, Step 19 is complete. Click the checkbox in the sidebar to save your progress.