terminal 103: pipes, redirects, and finding things terminal 103: pipes, redirects และการค้นหาให้เจอ

in terminal 102 you changed files one command at a time. useful, but still a bit manual.

this lesson is where the terminal starts to feel like a system instead of a list of separate commands.

you’ll do three things:

• send one command’s output into another with a pipe (|)
• save output to a file with redirects (> and >>)
• search and skim text with grep, head, tail, and history

once this clicks, you stop reading everything line by line. you ask the terminal for the part you actually need.

what you’ll know by the end

• how to connect commands with |
• how to save output to a file with >
• how to append new output to the end of a file with >>
• how to search for matching lines with grep
• how to preview just the first or last few lines with head and tail
• how to search your own command history instead of retyping from memory
• the safety rule for this lesson: > overwrites silently

what this assumes

just terminal 101 and terminal 102.

if pwd, ls, cd, cat, and rm make sense now, you’re ready.

6 ideas that make the terminal much more useful

the pattern is the same on Mac and Windows, but the simulator still keeps a few platform-specific command names:

• Mac: ls, cat, clear
• Windows in this lesson: dir, type, cls

two things matter here:

1. | keeps the output on its way to another command.
2. > and >> send the output into a file instead of showing it on screen.

try it yourself

walk through this in the terminal below:

1. ls | grep Desktop — find just the Desktop entry from your home folder Windows: dir | grep Desktop
2. cd Desktop — move into Desktop
3. grep invoice notes.txt — search the text file for one word
4. cat notes.txt | head -n 2 — show only the first 2 lines Windows: type notes.txt | head -n 2
5. cat notes.txt | tail -n 1 — show only the last line Windows: type notes.txt | tail -n 1
6. ls > files.txt — save the current folder listing into a file Windows: dir > files.txt
7. cat files.txt — read the file you just created Windows: type files.txt
8. echo checked >> files.txt — append one more line
9. cat files.txt — confirm the new line was added at the end Windows: type files.txt
10. history | grep ls — find the earlier ls commands in your own history Windows: history | grep dir

the important moment is step 6:

• > does not ask before replacing a file
• if files.txt already existed, its old contents would be gone

how a pipe actually works

read this from left to right:

cat notes.txt | grep invoice

• cat notes.txt prints the file
• |
• grep invoice receives that output and keeps only the matching line

so the pipe means:

“take what came out of the command on the left, and feed it into the command on the right”

that’s the whole idea.

you can chain more than two commands later, but for beginners, two is enough to build the mental model.

> vs >>

these two look similar, but the behavior is different:

ls > files.txt
echo checked >> files.txt

• > creates the file if needed, or replaces it if it already exists
• >> creates the file if needed, or adds to the end if it already exists

if you only remember one safety habit from this lesson, remember this:

pause before pressing Enter on any command with >

it is the same kind of habit as pausing before rm, just for a different reason. rm deletes the file. > deletes the old contents by overwriting them.

why grep, head, tail, and history matter

these are not “advanced hacker commands.” they’re the quickest way to avoid wasting attention.

• grep answers: “which lines mention this word?”
• head answers: “show me the beginning, not all of it”
• tail answers: “show me the end, not all of it”
• history answers: “what did I run earlier?”

that combination is already enough for a lot of day-to-day terminal work.

one real-world task

imagine you just want a tiny proof file showing what was in your Desktop folder and one note that you checked it.

do this:

1. cd Desktop
2. ls > desktop-list.txt Windows: dir > desktop-list.txt
3. echo reviewed >> desktop-list.txt
4. cat desktop-list.txt Windows: type desktop-list.txt
5. grep report desktop-list.txt

that’s a very small workflow, but it shows the bigger pattern:

• generate output
• save it
• add one more line
• search the result later

common mistakes

you use > when you meant >>. this is the big one. > replaces. >> appends.

you expect grep here to use full regex power. in this simulator, grep is intentionally plain-text substring matching so the lesson stays simple.

you try to write into a folder. ls > Desktop (or dir > Desktop on Windows) is not “put this in the Desktop folder.” it’s trying to write to a file called Desktop, and the shell should complain because Desktop is a directory.

you forget that head and tail can read from either a file or a pipe. both of these are valid:

head -n 2 notes.txt
cat notes.txt | head -n 2

you search everything manually instead of searching your history. if you already typed the command once, try history | grep word before retyping from scratch.

one note about rg

on a real machine, many developers use rg (ripgrep) for fast project-wide searching. this lesson keeps the interactive simulator focused on grep, because the important beginner idea is the pattern:

• search for matching text
• pipe the results
• trim the output down with head or tail

in the next setup-focused lesson, you’ll install tools like rg on a real Mac and start using them outside the simulator.

what this unlocks

now the terminal stops being one-command-at-a-time.

you can connect commands, capture output, search inside it, and keep only the part you need. that’s the workflow layer.

next up: terminal 104 — installing tools on macOS with Homebrew. that’s where commands like rg start showing up for real, and where “command not found” starts making sense instead of feeling random.