Learn › RHCSA (EX200) › Exam Orientation + Essential Tools
bash - a hands-on Linux lab on a real virtual machine.
Steer a command's two output streams. stdout and stderr, and for stdout, 2 for stderr, and the EX200 move that folds both into one file: command file 2&1. Plus splitting streams apart, the pipe, tee, and /dev/null.
You are on the exam. The task reads: run a command and save everything it prints into one file, /root/output, so the grader can read it back. You run the command. The normal output lands in the file. But the error message the command also printed is nowhere in that file. It flashed on your screen and disappeared.
You just met the fact that trips up more exam candidates than any flag: a command does not have one output. It has two. And the operator you reach for by reflex, the plain >, only catches one of them. This lesson is about seeing both, and steering each one exactly where the task wants it.
The black boxes below are a practice terminal: a safe sandbox that checks only the one command each step teaches, so you cannot break anything. Redirection sends output into files, so most reveals show the file's contents with cat. The scenario is fixed for every drill: your current folder holds a file called report.txt, and there is NO file called nope.txt.
Every Linux command opens three data streams. Learn their names once and every redirection operator falls into place.
stdout, file descriptor 1, is a command's normal answer: the directory listing, the matched lines, the report. stderr, file descriptor 2, is a command's complaints: the "No such file" messages, the warnings. Both print to your screen by default, which is why on the screen they look like one mixed stream. They are not. Redirection is the act of sending a stream somewhere other than its default, most often into a file. The number in front of an operator (like the 2 in 2>) picks WHICH stream you are steering.
The workhorse is >. It takes stdout, file descriptor 1, and writes it into a file instead of your screen. If the file does not exist, > creates it. If it does exist, > empties it first and then writes. That erase-first behavior is the operator's whole personality.
List report.txt, but instead of printing to the screen, send that output into a file named good.txt. Nothing prints, because stdout is now going to the file. To see the result, read the file back with cat. Run the two commands:
prompt: student@servera:~$ answer: ls report.txt > good.txt output: hint: Type ls, the filename report.txt, then a single greater-than sign and the target file good.txt.
prompt: student@servera:~$ answer: cat good.txt output: report.txt hint: cat prints a file to the screen. Point it at good.txt.
The first command printed nothing, and that silence is the proof it worked: stdout went into good.txt instead of the screen. cat good.txt then showed the one line report.txt, the normal output of ls, now living in a file. On the exam, the phrase "save the output of X to file Y" is exactly this: X > Y.
> erases the target before writing, with no prompt and no undo. echo x > /etc/fstab would wipe your fstab in an instant. When a task says "save" or "overwrite," > is right. When it says "append" or "add to," you want the operator in the next step instead.
Doubling the sign to >> changes one thing: it appends. It writes stdout to the END of the file and keeps whatever was already there. If the file does not exist yet, >> creates it, same as >. The difference only shows when the file already has content.
Write the word one into a fresh file with >, then add two with >>, then read it back. Before you run the last cat, decide what you expect to see: one line, or two?
prompt: student@servera:~$ answer: echo one > append.txt output: hint: echo prints its argument. Send it into append.txt with a single greater-than sign.
prompt: student@servera:~$ answer: echo two >> append.txt output: hint: Same echo, but this time use two greater-than signs so you add instead of overwrite.
prompt: student@servera:~$ answer: cat append.txt output: one two hint: cat the file you have been building, append.txt.
Two lines: one then two. Had you used > for the second write, two would have erased one and the file would hold a single line. Because >> appends, both survived, in the order you wrote them. That is the whole rule: > replaces, >> grows.
Now for the stream the plain > never touches. Errors travel on stderr, file descriptor 2, so you steer them with 2>: the 2 names the stream, the > sends it to a file. The exam move you are building toward is bigger, though: capture BOTH streams into one file so nothing escapes to the screen.
There are two ways to merge. The explicit one is > file 2>&1. Read it in order: > file first points stdout (fd 1) at the file, then 2>&1 says "send fd 2 wherever fd 1 is now pointing." Order is everything. 2>&1 copies stdout's CURRENT destination, so stdout must be aimed at the file first. Write it backwards as 2>&1 > file and fd 2 copies the screen (where fd 1 still was), so your errors leak to the terminal.
List two things at once, the real report.txt and the missing nope.txt, and send both the listing (stdout) and the error (stderr) into one file, out.txt. Then read it:
prompt: student@servera:~$ answer: ls report.txt nope.txt > out.txt 2>&1 output: hint: Point stdout at out.txt with > first, then add 2>&1 at the very end so stderr follows it.
prompt: student@servera:~$ answer: cat out.txt output: ls: cannot access 'nope.txt': No such file or directory report.txt hint: cat the merged file out.txt to see both streams together.
One file now holds both streams: the error about nope.txt from stderr AND the report.txt line from stdout. Nothing reached the screen. This is EX200 essential-tools task 5, the single most tested redirection: command > file 2>&1 captures everything a command emits into one file. Commit that shape to muscle memory. There is a shorthand, &>, that does the same job (ls report.txt nope.txt &> out.txt), but on the exam the safe, portable form to type is > file 2>&1.
The error text is byte-for-byte what AlmaLinux 10.2 printed. On your machine the wording is identical for a missing file, but if you point the command at different names the paths inside the message change to match. The lesson is the SHAPE: stderr carried the complaint, stdout carried the answer, and 2>&1 folded them together.
Merging is one exam move. The opposite is just as common: keep the good output and the errors in SEPARATE files. You already have both operators for it. Point stdout at one file with >, and in the same line point stderr at another with 2>. Each stream lands in its own place.
Run the same listing, but this time send the good result to good.txt and the error to err.txt. Verbally commit first: which file gets report.txt, and which gets the "No such file" line?
prompt: student@servera:~$ answer: ls report.txt nope.txt > good.txt 2> err.txt output: hint: One command, two redirects: > good.txt for stdout and 2> err.txt for stderr.
prompt: student@servera:~$ answer: cat good.txt output: report.txt hint: cat the file that caught stdout, good.txt.
prompt: student@servera:~$ answer: cat err.txt output: ls: cannot access 'nope.txt': No such file or directory hint: cat the file that caught stderr, err.txt.
Clean separation. good.txt holds only report.txt, the successful listing on stdout. err.txt holds only the complaint about nope.txt, the failure on stderr. The exam sometimes asks for exactly this: normal output to one file, errors to another. Two redirects on one line, one per stream, do it in a single pass.
Three more pieces round out the toolkit, and each answers a real exam need.
The pipe, |, does not touch files at all. It takes the stdout of the command on its left and feeds it as the stdin of the command on the right, so you can chain tools: ls report.txt | grep report. Note the limit: a pipe carries stdout ONLY. stderr still spills to your screen unless you fold it in first with 2>&1.
tee solves a specific problem: you want output saved to a file AND shown on screen at the same time. > can only do one or the other. Pipe into tee file and it writes to the file and passes the same text onward to the screen: ls report.txt | tee saved.txt.
/dev/null is a special file that throws away everything written to it, the system's trash can. When a command floods the screen with permission errors you do not care about, send stderr there: find / -name '*.conf' 2> /dev/null hides the noise and keeps the results. These three are exam staples; you do not drill them here, but you WILL use them on the real machine.
Scaffolding off. No command is shown. You have every piece.
A task hands you a command that lists two names, the real report.txt and the missing nope.txt. It must run, and BOTH its normal output and its error message must end up together in a single file called out.txt, with nothing left on the screen. Type the redirection that does it, then read out.txt back.
prompt: student@servera:~$ answer: ls report.txt nope.txt > out.txt 2>&1 output: hint: Aim stdout at the file first with > out.txt, then make stderr follow it. Think > out.txt, then 2>&1 at the end.
prompt: student@servera:~$ answer: cat out.txt output: ls: cannot access 'nope.txt': No such file or directory report.txt hint: cat the file you just wrote, out.txt.
That is the exam move, typed from memory. > out.txt pointed stdout at the file, and 2>&1 at the end sent stderr to the same place, so one file caught both the error and the listing. Written in the other order, 2>&1 > out.txt, the error would have leaked to the screen. You recalled the operators and their order without being shown, which is exactly what the grader will ask of you.
You earned this cheat sheet. Every row is an operator you just used or will reach for on the exam:
The one line to burn in: command > file 2>&1 captures everything into one file. > overwrites, >> appends, and the number in front of > (the 2 in 2>) picks the stream. Order matters in 2>&1: point stdout at the file first, fold stderr in second.
A classic exam trap: sudo command > /root/file fails with "Permission denied" because the shell opens the redirect as YOUR user before sudo runs, so it never gets root. Write it as command | sudo tee /root/file instead, and tee (running under sudo) does the writing.
The practice terminal has shown you the shape of redirection. The three streams, > and >> for stdout, 2> for stderr, the > file 2>&1 merge that the exam leans on, splitting streams into separate files, plus the pipe, tee, and /dev/null. Every command in those boxes you typed yourself.
The essential-tools module ends on one real RHEL 10 machine, the module mission, and that is where redirection stops being a drill. The capstone hands you a live servera with its own files and its own graded objectives. Several of them say "save the output" or "capture everything to a file." One difference from here: the mission shows no commands. You read the objective, recall the operator, and type it. That recall is what makes it stick under exam pressure.
Finish the other essential-tools lessons, then go redirect real output on a real machine.
Practice Shell Redirection in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.