Learn › Linux Foundations › I/O Redirection
Part 1 of 2: the three streams and their numbers, then , , <, 2, 2&1, & and /dev/null (Sections 11.1 to 11.9). No machine test here; it completes on the final step. The chapter lab waits at the end of Part 2.
This chapter covers the following topics:
This part covers Sections 11.1 to 11.9. Part 2 covers Sections 11.10 to 11.13.
You already know how to run commands. Now choose where their input comes from and where their output goes.
Objectives
By the end of this part, you will be able to:
The practice program always produces four result lines and two error lines. That makes each change easy to see. You will try one command at a time, then read back what it produced.
You will use cat, head, wc, hostname and whoami from earlier chapters. Most paths below start from your home directory; the accepted ~/io/... alternatives work from another directory too.
Before the practice machine starts, exercise cards show recorded examples and check each command. Once it is running, use the real Terminal for the steps in order and inspect the actual output and files. File changes persist when you open Part 2 in the same practice session; the new terminal starts a new shell. The chapter assessment uses a separate machine.
Try these short questions to check your starting point. The explanation will help you if you are unsure.
>>> The command writes to stdout, and the shell sets its destination before the command runs. In this lesson it starts at the terminal; redirection can connect it to a file instead. Section 11.1.
>>> Separate streams let you save normal results while keeping diagnostics visible. A message is not stderr merely because it is red or contains the word ERROR; the program chooses the stream. Section 11.6.
>>> With the normal Bash setting used here, > empties the existing file before the command writes. Use >> when you mean to keep its contents and append. Section 11.3.
>>> < connects the file to stdin. The command reads those bytes through its input stream; the path is not passed as a filename argument. This works with programs that read stdin. Section 11.5.
>>> Writes to /dev/null are discarded. Reads immediately reach the end of input. Choose which stream to discard; doing so does not fix the problem that produced a message. Section 11.9.
A command normally has three standard channels, called streams:
These numbers are file descriptors. In an ordinary interactive session, the streams connect to your terminal. Redirection changes a connection before the command runs.
You will use one small practice area, ~/io. From your home directory, try ls io to see what is available. If you are elsewhere, use ls ~/io.
prompt: admin@server1:~$ answer: ls io ||| ls io/ ||| ls ~/io ||| ls ~/io/ output: README.txt checklist.txt healthcheck out reset hint: Section 11.1. The listing tool from Chapter 2, then the directory io from your home directory, or ~/io from anywhere.
The five names are the practice files and tools. healthcheck produces predictable results and errors; checklist.txt supplies input. out holds your saved results. The next step reads the instructions in README.txt.
If ls cannot find io, check your location with pwd, or use the accepted ~/io path.
Before changing files, find out which ones are safe to practice with.
Try cat io/README.txt. Look for where results are stored and what the reset tool changes.
prompt: admin@server1:~$ answer: cat io/README.txt ||| cat ~/io/README.txt output: io: the redirection practice area of server1.
healthcheck a program that writes four passing checks to stdout and two failing checks to stderr, the same six lines every run checklist.txt eight lines of input for < and for the pipe chains reset rebuilds out/ to the state it had at boot out/stdout results of the > and >> and < exercises out/stderr results of the 2> and &> and 2>&1 exercises out/pipes results of the | and tee exercises
Five result files already hold a line or two at boot: once.txt, roll.txt and operator.txt under out/stdout, and journal.txt and digest.txt under out/pipes. The exercises that truncate and append need something to work on.
Run io/reset at any time to put out/ back the way it started. hint: Section 11.1. The reader from Chapter 5, then the path io/README.txt from your home directory, or ~/io/README.txt from anywhere.
Your results go into io/out/stdout, io/out/stderr and io/out/pipes. Some files already contain a starting line so you can compare replacing with appending.
On the real machine, io/reset rebuilds all of io/out, not just the last file. Use it only when you want to restart the file exercises. It removes results you created there.
The input for this chapter is an eight-line checklist. Reading it now makes later counts and copies easy to verify.
Try cat io/checklist.txt. Notice the first line, about the web server, and the last line, about the system clock.
prompt: admin@server1:~$ answer: cat io/checklist.txt ||| cat ~/io/checklist.txt output: check the web server responds check disk space on the root filesystem check the nightly backup ran check the certificate expiry date check the log rotation ran check the mail queue is draining check the firewall rules are loaded check the system clock is in step hint: Section 11.1. The same reader, then the path io/checklist.txt from your home directory, or ~/io/checklist.txt from anywhere.
There are eight lines. You will feed these same bytes to commands using < and |. Neither operator changes the text by itself.
If a later result has a different count, check whether the command trimmed, duplicated or appended these lines.
io/healthcheck is a practice program. It always writes four OK lines to stdout and two ERROR lines to stderr. These are fixed examples, not a diagnosis of your own computer.
Try io/healthcheck from your home directory. Both streams currently reach the terminal, so you should see six lines.
prompt: admin@server1:~$ answer: io/healthcheck ||| ./io/healthcheck ||| ~/io/healthcheck output: OK web server responds on port 80 ERROR log rotation has not run OK disk space is above the threshold OK the nightly backup was verified ERROR the mail queue is not draining OK the certificate is valid hint: Section 11.1. The path to the program inside the io directory, io/healthcheck from your home directory or ~/io/healthcheck from anywhere, and nothing else on the line.
All six lines appear together. In this program, OK lines use stdout and ERROR lines use stderr. The words themselves do not choose the stream; the program does.
Next you will save the results while leaving the errors visible. If the program is not found, use ~/io/healthcheck.
Use > when you want to save a command's stdout in a file.
Worked command: io/healthcheck > io/out/stdout/checks.txt
io/healthcheck runs the check.> sends stdout to the path on its right.io/out/stdout/checks.txt receives the four OK lines.Try the command. Expect the two ERROR lines on the terminal because stderr has not moved. Under the normal Bash setting, > creates the file or replaces its existing contents.
prompt: admin@server1:~$ answer: io/healthcheck > io/out/stdout/checks.txt ||| io/healthcheck >io/out/stdout/checks.txt ||| io/healthcheck 1> io/out/stdout/checks.txt ||| ~/io/healthcheck > ~/io/out/stdout/checks.txt output: ERROR log rotation has not run ERROR the mail queue is not draining hint: Section 11.2. The program io/healthcheck, the operator that attaches stream 1 to a file, >, then the path io/out/stdout/checks.txt. Write both paths with ~/ in front to run the line from anywhere.
The error messages are expected here. They show that > redirected stdout only; they do not mean the redirect failed. The next step checks the saved file.
If Bash reports a missing directory, check the destination path. > creates a file, but it does not create its parent directories.
A quiet terminal does not prove that a file is correct. Read the saved result to check it.
Try cat io/out/stdout/checks.txt. Expect four OK lines and no ERROR lines.
prompt: admin@server1:~$ answer: cat io/out/stdout/checks.txt ||| cat ~/io/out/stdout/checks.txt output: OK web server responds on port 80 OK disk space is above the threshold OK the nightly backup was verified OK the certificate is valid hint: Section 11.2. The reader from Chapter 5, then the path you redirected into, io/out/stdout/checks.txt (or ~/io/out/stdout/checks.txt from anywhere).
The file holds stdout from the previous step. The two errors stayed on stderr and were never saved here.
If the file is missing on the real machine, return to the preceding step and create it. If it includes errors, check whether you used a merge operator instead of plain >.
Truncate means reduce a file to zero bytes. With normal Bash settings, > does this before the command runs, then writes the new output.
Never use the same file as both the input and the > destination. For example, cat report.txt > report.txt empties the file before cat can read it.
First inspect the safe practice file with head -n 3 io/out/stdout/once.txt. These are the three lines you will replace.
prompt: admin@server1:~$ answer: head -n 3 io/out/stdout/once.txt ||| head -n 3 ~/io/out/stdout/once.txt output: placeholder line one placeholder line two placeholder line three hint: Section 11.3. The tool that prints the start of a file, with a count of three and the path io/out/stdout/once.txt (or ~/io/out/stdout/once.txt from anywhere).
The file starts with three placeholder lines. The next step replaces them with the machine name.
If you are revisiting this on a real machine, earlier work may already have changed the file. io/reset restores all starting files under io/out, so save any results you want to keep before using it.
Now replace those three lines with one machine name.
Try hostname > io/out/stdout/once.txt. hostname produces server1; > sends it to the file. Expect no normal output on the terminal.
prompt: admin@server1:~$ answer: hostname > io/out/stdout/once.txt ||| hostname >io/out/stdout/once.txt ||| hostname 1> io/out/stdout/once.txt ||| hostname > ~/io/out/stdout/once.txt output: hint: Section 11.3. The Chapter 1 command that prints the machine name, the stream 1 operator >, then the path io/out/stdout/once.txt (or ~/io/out/stdout/once.txt, which puts the file in the same place from anywhere).
No output is expected because stdout goes to the file. Silence alone is not a success check; read the file in the next step.
Use a single > for this task. >> would keep the old lines and add the name after them.
Check the result with cat io/out/stdout/once.txt.
Expect one line, server1. The three placeholder lines should no longer be present.
prompt: admin@server1:~$ answer: cat io/out/stdout/once.txt ||| cat ~/io/out/stdout/once.txt output: server1 hint: Section 11.3. The reader from Chapter 5 and the path of the file you just wrote, io/out/stdout/once.txt (or ~/io/out/stdout/once.txt from anywhere).
One line remains because > replaced the old contents. The shell does not keep an undo copy for you.
If the placeholders remain, check whether you used >>. The next example uses that operator deliberately to keep existing text.
Use >> to append: keep what is already in a file and add new output at the end. Like >, it creates the file if needed.
Before appending, inspect the first line with head -n 1 io/out/stdout/roll.txt. It is a label that should survive the next command.
prompt: admin@server1:~$ answer: head -n 1 io/out/stdout/roll.txt ||| head -n 1 ~/io/out/stdout/roll.txt output: recorded by: hint: Section 11.4. The tool that prints the start of a file, with a count of one and the path io/out/stdout/roll.txt (or ~/io/out/stdout/roll.txt from anywhere).
The label is recorded by:. Keep that line and add the machine name below it.
Remember the choice: > replaces; >> adds. Neither operator inserts a newline of its own. The command supplying the text decides where its lines end.
Add the machine name without removing the label.
Try hostname >> io/out/stdout/roll.txt once. The two > characters form one operator, with no space between them. Expect no normal output on the terminal.
prompt: admin@server1:~$ answer: hostname >> io/out/stdout/roll.txt ||| hostname >>io/out/stdout/roll.txt ||| hostname >> ~/io/out/stdout/roll.txt output: hint: Section 11.4. The same machine-name command, the doubled operator that adds instead of replacing, >>, then the path io/out/stdout/roll.txt (or ~/io/out/stdout/roll.txt from anywhere).
The new line was sent to the file. Read it next to confirm that the label stayed.
On the real machine, running an append again adds another line. If you accidentally repeat it, do not assume the second run replaced the first.
Try cat io/out/stdout/roll.txt to check the append.
Expect the original label followed by server1: two lines in total.
prompt: admin@server1:~$ answer: cat io/out/stdout/roll.txt ||| cat ~/io/out/stdout/roll.txt output: recorded by: server1 hint: Section 11.4. The reader from Chapter 5 and the path io/out/stdout/roll.txt (or ~/io/out/stdout/roll.txt from anywhere).
The label survived, and the machine name appears below it. That is the difference between append and replace.
If you see the machine name twice, the append ran twice. To restart, io/reset restores all result files, so you will need to redo any earlier file work you want to keep.
Use the same idea with another source of output. whoami prints the account running the command.
Try whoami >> io/out/stdout/operator.txt once. This file starts with run by:; your account name should be added underneath.
prompt: admin@server1:~$ answer: whoami >> io/out/stdout/operator.txt ||| whoami >>io/out/stdout/operator.txt ||| whoami >> ~/io/out/stdout/operator.txt output: hint: Section 11.4. The Chapter 1 command that prints your account name, the doubled operator >>, then the path io/out/stdout/operator.txt (or ~/io/out/stdout/operator.txt from anywhere).
The command sends admin to the file, so nothing normally prints on the terminal. The next step checks that the label was preserved.
Check the target name before pressing Enter: operator.txt is a different file from roll.txt.
Try cat io/out/stdout/operator.txt.
Expect the label run by: and then admin.
prompt: admin@server1:~$ answer: cat io/out/stdout/operator.txt ||| cat ~/io/out/stdout/operator.txt output: run by: admin hint: Section 11.4. The reader from Chapter 5 and the path io/out/stdout/operator.txt (or ~/io/out/stdout/operator.txt from anywhere).
The two lines show that existing text was kept and the account name was appended. This pattern is useful for adding a new record to a text log.
If the label is missing, the file was probably replaced with > instead of appended with >>.
Use < to make a file the command's standard input. The command must support reading stdin; wc does.
Worked command: wc -l < io/checklist.txt
The shell opens the checklist on stdin, and wc -l counts its lines. Try it. Expect 8, with no filename after the count.
prompt: admin@server1:~$ answer: wc -l < io/checklist.txt ||| wc -l <io/checklist.txt ||| wc -l 0< io/checklist.txt ||| wc -l < ~/io/checklist.txt output: 8 hint: Section 11.5. The counting tool with its line option -l, then the operator that attaches stream 0 to a file, <, then the path io/checklist.txt (or ~/io/checklist.txt from anywhere).
wc received input on stdin without a filename argument, so it prints only the count. < is short for 0<.
If the command waits for you to type, check whether the in
Practice Chapter 11, Part 1. I/O Redirection: the three streams, >, >>, <, 2>, 2>&1 and /dev/null in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.