Standard Streams and Redirection: A Linux Guide for Developers

Previously in this course, we covered Advanced Text Editing with Vim. Now that you can create and modify files, this lesson adds the ability to capture command output directly into those files using redirection.

The Three Standard Streams

In Linux, every process starts with three default communication channels, known as "standard streams." When you run a command, it typically reads input from your keyboard and writes output to your terminal screen.

• stdin (Standard Input, file descriptor 0): The stream where a command reads data. By default, this is your keyboard.
• stdout (Standard Output, file descriptor 1): The stream where a command sends its normal, successful output. By default, this is your terminal screen.
• stderr (Standard Error, file descriptor 2): The stream where a command sends error messages or diagnostic information. This also defaults to your terminal screen.

Redirection allows you to "re-route" these streams. Instead of letting stdout or stderr clutter your screen, you can save them to a file—an essential skill for managing the logs of your web server project.

Redirecting stdout with > and >>

The most common task is capturing the output of a command.

Overwriting with >

The > operator redirects stdout to a file. If the file exists, it will be completely overwritten.

Bash
# Save a list of files into a log file
ls -l > ~/web-server/logs/file_list.txt

Appending with >>

If you want to add data to the end of a file without destroying existing content, use >>. This is the standard way to maintain log files.

Bash
# Append the current date to our log file
date >> ~/web-server/logs/file_list.txt

Redirecting Errors with 2>

Sometimes a command fails, and you want to capture the error separately from the success messages. Because stderr is identified by the number 2, we use 2> to redirect it.

Consider this example where we intentionally try to list a non-existent file:

Bash
# This will fail and show an error on the screen
ls non_existent_file.txt

# Capture the error message to a file instead
ls non_existent_file.txt 2> ~/web-server/logs/error.log

If you check the contents of error.log using cat, you'll see the error message captured there, while your terminal remains clean.

Hands-on Exercise: Logging Server Status

Let’s apply this to our running web server project. We want to capture information about our directory structure into a log file.

1. Navigate to your project directory.
2. Run ls -l and redirect the output into logs/server_status.log.
3. Try to list a directory that doesn't exist (e.g., ls /fake/path) and redirect the error into logs/error.log.
4. Append the current date to logs/server_status.log.

Common Pitfalls

• Overwriting by Accident: Using > when you meant >> is a classic mistake. Always double-check your operator if you are writing to a file that already contains important data.
• Confusing 1> and >: In Bash, > is shorthand for 1>. They do the exact same thing (redirecting stdout).
• Forgetting the File Descriptor: If you type ls 2 > error.log, the shell thinks you want to list the file named "2" and redirect its output to "error.log," rather than redirecting standard error. Always keep the operator attached: 2>.

FAQ

Q: Can I redirect both stdout and stderr to the same file? A: Yes. You can use &> to redirect both streams to a single file simultaneously.

Q: Does redirection work with every command? A: Yes, because redirection is handled by the shell (Bash), not the command itself. The command doesn't even know its output is being sent to a file instead of the screen.

Q: What happens if I don't have permission to write to a file? A: The shell will return a "Permission denied" error, and the file will not be created or modified.

Recap

We've learned that standard streams (stdin, stdout, stderr) are the backbone of Linux data flow. By using > to overwrite, >> to append, and 2> to capture errors, you can transform the terminal from a simple display into a powerful tool for automated logging and data management.

Up next: Piping Commands Together