Learn › Linux Foundations › I/O Redirection
&> - a hands-on Linux lab on a real virtual machine.
One operator to capture everything a command says. Watch a plain let the stderr line escape to the screen, catch both channels in one file with &, verify the complete record, and learn to choose between , 2, and & on purpose.
Night watch in the signal room. Your job is simple: keep a complete record of everything the status script says. Not just the good news. Everything, complaints included.
You know the tool for this. The > operator from the output redirect lesson pours a command's results into a file. So point report.sh at a file and the whole report should be safe on disk.
Except it will not be. Run it and exactly one line refuses to go. It lands on your screen anyway, as if the redirect were not even there. This lesson is about that stubborn line, and the one operator that finally catches it.
The black boxes below are a practice terminal: a safe sandbox that only checks the one command each step teaches, so you cannot break anything. You are working inside the signal folder in your home directory, with the same report.sh status script from the earlier lessons. On the real machine at the end of the module, the capstone mission builds this same folder and you run these moves for real.
Try the capture the way you already know. Remember the rule from the > lesson: redirect a command's output to a file and the screen stays silent, because everything went to disk.
bash report.sh > all.txt
Before you run it, commit to a prediction: will the screen stay silent this time?
prompt: student@linuxcamp:~/signal$ answer: bash report.sh > all.txt output: report: sensor offline hint: The > operator you already know, aimed at a file: bash report.sh > all.txt
Not silent. One line dodged the redirect and hit your screen anyway: report: sensor offline, the complaint.
You already know why, from the file descriptors lesson. A command has two output channels. Routine results travel on stdout, channel 1. Complaints travel on stderr, channel 2. A plain > is really 1>: it moves channel 1 only. So the two routine lines went into all.txt, and the complaint sailed straight past the redirect to your screen.
Your record has a hole in it. And 2> from the last lesson has the same problem in mirror image: it would file the complaint and let the results escape instead. Neither operator alone can capture the whole story.
The fix is one character bigger. The &> operator redirects BOTH output channels at once. Read command &> file as "run the command and pour channel 1 and channel 2 into file, together." Nothing escapes to the screen, because both doors now lead to the same place.
Where > grabs the results and 2> grabs the complaints, &> grabs everything. That is the whole operator. One warning carries over from >: &> also overwrites the file it targets, starting it fresh each time.
The &> spelling is a bash invention; the older C shell wrote the same idea as >&, and bash quietly accepts that form too. There is also a longer, classic spelling that works in every shell. It is built from an operator called 2>&1, and it gets its own lesson next.
Same capture, one character different:
bash report.sh &> all.txt
Before you run it, decide: what will the screen show this time, and where will the complaint end up?
prompt: student@linuxcamp:~/signal$ answer: bash report.sh &> all.txt output: hint: Same shape as the > attempt, but with the catch-everything operator: bash report.sh &> all.txt
Silence, and this time silence means success. Remember the rule: a blank screen after a redirect means everything went to the file. With &> there was nothing left to escape. Channel 1 and channel 2 both poured into all.txt, and because &> overwrites, the holey record from your first attempt is gone too.
The complaint is finally on disk. Prove it.
cat all.txt
Before you run it, commit: how many lines will the file hold, and which line will be last?
prompt: student@linuxcamp:~/signal$ answer: cat all.txt output: report: system nominal report: all checks passed report: sensor offline hint: Read the file back with cat: cat all.txt
Three lines. The first two are the routine results, and the last one is the escapee, report: sensor offline, finally captured in the same file. When both channels pour into one file, the order is fixed: results first, complaint last.
Look at what one character did. > all.txt gave you two lines and a leak. &> all.txt gave you the complete record. That is the milestone of this lesson: you can now capture everything a command says, results and complaints, with one operator.
This is exactly how unattended scripts keep their logs. A backup job that runs overnight with nobody watching gets started as job &> job.log, so whatever it says, routine or disastrous, is waiting on disk in the morning.
Scaffolding off. No command is shown from here on.
The watch is changing and the log must be complete. Run the status report so that every line it says, results and complaint alike, lands in all.txt, and nothing at all appears on the screen.
prompt: student@linuxcamp:~/signal$ answer: bash report.sh &> all.txt ||| bash report.sh >& all.txt ||| bash report.sh > all.txt 2>&1 output: hint: One operator catches both channels at once. Aim it at all.txt.
A bare prompt, and you knew that meant success before checking anything: with both channels captured, there was nothing left to print.
A record you cannot read back is no record at all. Print the contents of the log so you can see with your own eyes that all three lines, complaint included, made it in.
prompt: student@linuxcamp:~/signal$ answer: cat all.txt output: report: system nominal report: all checks passed report: sensor offline hint: You read this same file back once already in this lesson.
All three lines, safe on disk. Capture with &>, verify by reading the file back. That pair is the habit: never trust a silent redirect until you have seen what landed.
One last test, because choosing the RIGHT operator is the real skill. Rewrite the log so it holds only the two routine result lines, and let the complaint hit your screen where you can watch it live.
prompt: student@linuxcamp:~/signal$ answer: bash report.sh > all.txt ||| bash report.sh 1> all.txt output: report: sensor offline hint: This is the operator from your first attempt, the one that moves only channel 1.
The leak from your first attempt, recreated on purpose. Now it is not a bug, it is a choice: > when you want results only, 2> when you want complaints only, &> when you want everything. Same command, three operators, three different splits.
You earned this cheat sheet. Every row is a move you just ran in the signal folder:
The one idea under all of it: &> is not a new kind of redirect, it is > with wider arms. One channel or both, the choice is a single character, and now you make it on purpose.
Keep &> glued together as one symbol. A & on its own means something completely different (it runs a command in the background, a later module), so cmd & > file does not do what you want. And like >, the &> operator overwrites; when you need to append both channels instead, bash offers &>>, the >> cousin.
You watched one line escape a plain >, caught it with &>, read back the complete three-line record, and then ran the capture, the proof, and the on-purpose leak from memory.
Next lesson meets 2>&1, the classic long spelling behind &>. It works in shells where &> does not, and it unlocks a move &> cannot make: sending both channels into a pipe.
The io-redirection module ends with one real Linux machine: the redirection mission lab. There a VM boots just for you with this same signal folder, and the mission hands you objectives that use exactly what you just ran, with no commands shown. You read the objective, recall the operator, and type it. That recall is what makes it stick. Finish the module's lessons, then go run the mission for real.
Practice Redirect All: &> in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.