RED HAT ENTERPRISE LINUX

I/O Redirection
in Bash

Controlling Command Input and Output

CIS126RH | RHEL System Administration 1
Mesa Community College

Welcome to this important module on input/output redirection in Bash. This is one of the most powerful features of the Unix/Linux command line - the ability to control where commands get their input and where they send their output. Instead of always reading from the keyboard and writing to the screen, commands can read from files, write to files, and most powerfully, connect to each other through pipes. This capability transforms simple commands into powerful data processing pipelines. Understanding redirection is essential for system administration tasks like logging, data processing, and automation. By the end of this module, you'll be able to redirect standard output and standard error to files, provide input from files, and chain commands together with pipes to create efficient workflows.

Learning Objectives

Understand standard streams

Know stdin, stdout, and stderr and their file descriptors

Redirect output to files

Use > and >> to capture stdout and stderr

Redirect input from files

Use < and here documents to provide input

Connect commands with pipes

Build powerful command pipelines using |

We have four learning objectives for this module. First, we'll understand the three standard streams that every Linux process has: standard input, standard output, and standard error. These streams are identified by file descriptors - numbers that the system uses to track them. Second, we'll learn to redirect output to files, both creating new files and appending to existing ones. We'll handle stdout and stderr separately and together. Third, we'll redirect input, providing data to commands from files instead of the keyboard, including the powerful here document syntax. Fourth, we'll master pipes - the vertical bar that connects the output of one command to the input of another. Pipes let you build complex data processing workflows from simple commands. These redirection skills are fundamental to shell scripting and efficient command-line work.

Standard Streams

Every Linux process has three standard streams for data flow. By default, they connect to the terminal, but redirection changes where data flows.

stdin

Standard Input
Data going INTO the command
Default: Keyboard

stdout

Standard Output
Normal output FROM command
Default: Terminal screen

stderr

Standard Error
Error messages FROM command
Default: Terminal screen

Every process in Linux has three standard communication channels called streams. Standard input, or stdin, is where a process receives input data. By default, this is the keyboard - when a command waits for input, it reads from stdin. The file descriptor for stdin is 0. Standard output, or stdout, is where a process sends its normal output. By default, this goes to the terminal screen. When ls lists files or cat displays content, that's stdout. The file descriptor is 1. Standard error, or stderr, is where a process sends error messages. This is also the terminal by default, but it's a separate stream from stdout. The file descriptor is 2. Why separate stdout and stderr? So you can handle them differently. You might want to save normal output to a file while still seeing errors on screen, or vice versa. The file descriptors (0, 1, 2) are important because you'll use them in redirection syntax. Understanding these three streams is the foundation for all redirection operations.

Default Data Flow

Keyboard

→ stdin (0) →

Command

→ stdout (1) →

Screen

Command

→ stderr (2) →

Screen

Key Insight: stdout and stderr both go to the screen by default, but they're separate streams that can be redirected independently.

This diagram shows the default data flow for a typical command. By default, stdin comes from the keyboard. When you run a command that expects input, like cat without arguments, it waits for you to type. Standard output goes to the terminal screen. When ls lists files, that output flows through stdout to your display. Standard error also goes to the terminal screen by default. When a command produces an error message, like "file not found," that flows through stderr. The key insight is that stdout and stderr are separate streams even though they both display on your screen by default. This separation is intentional - it lets you handle normal output and error messages differently. For example, you might redirect stdout to a file to capture results while letting errors display on screen so you notice them immediately. Or in a script, you might redirect errors to a log file while displaying normal output to the user. Redirection gives you precise control over where each stream goes.

Output Redirection Operators

Operator	Description	Example
>	Redirect stdout to file (overwrite)	ls > files.txt
>>	Redirect stdout to file (append)	echo "text" >> log.txt
2>	Redirect stderr to file (overwrite)	cmd 2> errors.txt
2>>	Redirect stderr to file (append)	cmd 2>> errors.txt
&>	Redirect both stdout and stderr	cmd &> all.txt
2>&1	Redirect stderr to same place as stdout	cmd > out.txt 2>&1

Here are the output redirection operators you'll use constantly. The greater-than symbol redirects stdout to a file. If the file exists, it's overwritten - this is important to remember as you can accidentally destroy data. If it doesn't exist, it's created. Double greater-than appends to the file instead of overwriting. This is safer for log files where you want to add new content without losing old content. For stderr, prefix with 2 (the file descriptor number): 2> redirects stderr to a file, overwriting, and 2>> appends. This lets you capture error messages separately from normal output. The ampersand-greater-than (&>) redirects both stdout and stderr to the same file. This is a bash shorthand that's convenient when you want all output in one place. The 2>&1 syntax redirects stderr to "wherever stdout is going." The order matters: you typically redirect stdout first, then add 2>&1 to send stderr to the same place. These operators form the foundation of output control in the shell.

Redirecting stdout

# Redirect output to new file (overwrites if exists!)
ls -l /etc > etc_listing.txt

# View the captured output
cat etc_listing.txt
total 1348
drwxr-xr-x.  3 root root    4096 Nov  1 10:00 abrt
-rw-r--r--.  1 root root      16 Nov  1 10:00 adjtime
...

# Append to existing file (preserves content)
echo "Listing generated on $(date)" >> etc_listing.txt

# Create empty file (or truncate existing)
> empty_file.txt

# Overwrite protection with noclobber
set -o noclobber          # Enable protection
ls > existing.txt         # Error if file exists
ls >| existing.txt        # Force overwrite anyway
set +o noclobber          # Disable protection

Let's see stdout redirection in practice. The command "ls -l /etc > etc_listing.txt" runs ls and captures all output in the file instead of displaying it on screen. Nothing appears on your terminal because stdout was redirected. If etc_listing.txt already existed, it's now overwritten with the new content. The previous contents are gone. This is why the append operator (>>) is often safer - it adds to the file rather than replacing it. The echo command with >> adds a timestamp at the end of the file without disturbing the ls output above it. An interesting trick: just "> empty_file.txt" with no command creates an empty file, or truncates an existing file to zero bytes. This is because the shell sets up the redirection (creating or truncating the file) before running the command - and there's no command to produce output. The noclobber option provides protection against accidental overwrites. With set -o noclobber enabled, trying to redirect to an existing file produces an error. Use >| to force overwrite when you really mean it. This can be a useful safety net when working with important files.

Redirecting stderr

# Command that produces both stdout and stderr
ls /etc /nonexistent
/etc:
hostname  hosts  passwd ...

ls: cannot access '/nonexistent': No such file or directory

# Redirect only stderr to file
ls /etc /nonexistent 2> errors.txt
/etc:
hostname  hosts  passwd ...

# Check the error file
cat errors.txt
ls: cannot access '/nonexistent': No such file or directory

# Discard stderr (send to /dev/null)
ls /etc /nonexistent 2> /dev/null
/etc:
hostname  hosts  passwd ...

# Append errors to log file
find / -name "*.conf" 2>> search_errors.log

Stderr redirection is essential for handling error messages separately from normal output. In the first example, ls tries to list two directories. /etc exists, so its listing goes to stdout. /nonexistent doesn't exist, so the error message goes to stderr. Both display on your terminal by default. Adding 2> errors.txt redirects only stderr. Now the directory listing still displays (stdout goes to terminal), but the error message is captured in errors.txt. This separation is valuable - you see the results but can review errors later. A common pattern is redirecting stderr to /dev/null - the "black hole" device that discards anything written to it. This suppresses error messages when you don't care about them, like running find across the filesystem where you'll get many "Permission denied" errors for directories you can't access. For logging purposes, 2>> appends errors to a log file. This is useful in scripts where you want to accumulate error messages over time without losing earlier ones. Understanding stderr redirection helps you create cleaner output and better logs.

Combining stdout and stderr

# Method 1: Redirect both to same file (bash shorthand)
ls /etc /nonexistent &> all_output.txt

# Method 2: Redirect stdout, then stderr to same place
ls /etc /nonexistent > all_output.txt 2>&1

# ORDER MATTERS! This is WRONG:
ls /etc /nonexistent 2>&1 > output.txt   # stderr still goes to terminal!

# Redirect to separate files
ls /etc /nonexistent > stdout.txt 2> stderr.txt

# Append both to same file
command >> combined.log 2>&1

# Discard all output (stdout and stderr)
command &> /dev/null
command > /dev/null 2>&1   # Same effect, more portable

⚠ Order Matters: In cmd > file 2>&1, redirect stdout first, then point stderr to it. Reversed order doesn't work!

Often you want to capture or redirect both stdout and stderr together. The &> operator is a bash shorthand that redirects both streams to the same file. It's clean and easy to remember. The traditional method is "> file 2>&1" which first redirects stdout to the file, then redirects stderr to wherever stdout is going (which is now the file). Both streams end up in the same file. Order is critical here. "2>&1 > file" does NOT work as expected because it redirects stderr to where stdout is currently going (the terminal), THEN redirects stdout to the file. Stderr still goes to the terminal! Always redirect stdout first, then add 2>&1. You can redirect to separate files with "> stdout.txt 2> stderr.txt" - useful when you want to examine normal output and errors independently. For scripts that should run silently, "command &> /dev/null" discards all output. The longer form "> /dev/null 2>&1" is more portable across different shells. These patterns for combining streams are used constantly in scripts and cron jobs where you need precise control over output.

Input Redirection

# Redirect input from a file
wc -l < /etc/passwd
45

# Compare: command reads file vs shell provides input
wc -l /etc/passwd         # wc opens the file (shows filename)
45 /etc/passwd

wc -l < /etc/passwd       # shell provides content (no filename)
45

# Send email from file
mail -s "Report" user@example.com < report.txt

# Combine input and output redirection
sort < unsorted.txt > sorted.txt

# Multiple redirections
command < input.txt > output.txt 2> errors.txt

Subtle Difference: With <, the shell opens the file and feeds it to the command. The command doesn't know the filename.

Input redirection provides data to a command from a file instead of the keyboard. The less-than symbol redirects stdin from a file. The command receives the file contents as if you had typed them. Notice the subtle difference in the wc examples. When wc opens the file itself (wc -l /etc/passwd), it knows the filename and includes it in the output. When the shell provides the content via redirection (wc -l < /etc/passwd), wc just receives data on stdin - it has no idea where the data came from, so it doesn't print a filename. This distinction matters in scripts where you might want clean output without filenames. You can combine input and output redirection in a single command. "sort < unsorted.txt > sorted.txt" reads from one file, sorts the content, and writes to another. This is a pattern for file transformation. The most complex form redirects all three streams: input from a file, output to one file, errors to another. This gives you complete control over the data flow for any command.

Here Documents

A here document (heredoc) provides multi-line input inline in a script or command, without needing a separate file.

# Basic here document syntax
cat << EOF
This is line 1
This is line 2
Variables expand: $HOME
EOF

# Prevent variable expansion with quotes
cat << 'EOF'
Variables do NOT expand: $HOME
This prints literally: $(whoami)
EOF

# Use in scripts to create files
cat << EOF > config.txt
server=localhost
port=8080
user=$USER
EOF

# The delimiter can be any word (EOF is convention)
cat << MYEND
Content here
MYEND

Here documents provide a way to include multi-line input directly in a script or command line, without creating a separate file. The syntax is << followed by a delimiter word (EOF is conventional but any word works). Everything until a line containing only that delimiter becomes input to the command. In the first example, cat receives three lines of input, including variable expansion - $HOME becomes your actual home directory path. The output displays on the terminal. When you quote the delimiter ('EOF' or "EOF"), variable expansion is disabled. The literal strings $HOME and $(whoami) appear in the output rather than their values. This is important when creating scripts or configurations that themselves use variables. Here documents are commonly used to create configuration files in scripts. The example combines a here document with output redirection to create config.txt with the specified content, including the expanded $USER variable. The delimiter must appear alone on its own line to end the here document. If your content might contain EOF, use a different delimiter. The pattern is extremely useful for creating multi-line file content, sending formatted emails in scripts, or providing multi-line input to interactive commands.

Here Strings

# Here string - single line input
wc -w <<< "count the words in this string"
6

# Useful with commands that read stdin
bc <<< "5 * 4 + 3"
23

# With variables
greeting="Hello World"
cat <<< "$greeting"
Hello World

# Compare: echo with pipe vs here string
echo "test data" | wc -c     # Creates subshell
wc -c <<< "test data"        # No subshell

# Read first field from string
read first rest <<< "apple banana cherry"
echo $first
apple

Here Strings are simpler than here documents for single-line input, and more efficient than echo | command.

Here strings provide a concise way to pass a single line of input to a command. The syntax is three less-than signs followed by a quoted string. The string becomes stdin for the command. In the wc example, the words in the string are counted without needing echo and a pipe. The bc calculator example shows how here strings work with interactive commands - bc normally reads expressions from stdin, and the here string provides one. Here strings expand variables when double-quoted. The greeting variable's value becomes the input to cat. Compared to "echo string | command", here strings are slightly more efficient because they don't create a subshell for the echo command. This rarely matters for performance, but here strings are also more concise and arguably cleaner syntax. A practical use is with the read command to parse strings. The example reads the first word into $first and the rest into $rest. This is handy for extracting parts of strings in scripts. Here strings are a bash feature - they're not available in all shells, so they're more common in scripts specifically written for bash.

Pipes

A pipe connects the stdout of one command directly to the stdin of another, creating a data processing pipeline.

Command 1

→ stdout → | → stdin →

Command 2

# Basic pipe - output of ls becomes input to wc
ls /etc | wc -l
245

# Filter output through grep
cat /etc/passwd | grep "bash"

# Chain multiple commands
cat /var/log/messages | grep "error" | wc -l

# Sort and remove duplicates
cut -d: -f7 /etc/passwd | sort | uniq

Pipes are one of the most powerful features of the Unix shell. The pipe symbol (vertical bar) connects the stdout of the command on the left to the stdin of the command on the right. Data flows from one command directly into another. In the first example, ls outputs the contents of /etc. Instead of displaying on screen, that output flows through the pipe to wc -l, which counts lines. The result: the number of items in /etc. Pipes let you combine simple tools to accomplish complex tasks. grep filters lines matching a pattern, so "cat /etc/passwd | grep bash" shows only lines containing "bash" - users with bash as their shell. You can chain multiple pipes. The messages log example first greps for error, then counts those lines. Each pipe adds a processing stage. The final example extracts the seventh field from /etc/passwd (the login shell), sorts them alphabetically, and removes duplicates - giving you a unique list of shells used on the system. Each command (cut, sort, uniq) does one thing well, and pipes combine them into something powerful. This "small tools, combined with pipes" philosophy is fundamental to Unix.

Building Pipelines

cat access.log

grep "404"

cut -d' ' -f7

sort

uniq -c

sort -rn

# Find most common 404 errors in web log
cat access.log | grep "404" | cut -d' ' -f7 | sort | uniq -c | sort -rn

# Step by step:
cat access.log            # Read the log file
  | grep "404"            # Keep only 404 error lines
  | cut -d' ' -f7         # Extract the URL field
  | sort                  # Sort URLs alphabetically
  | uniq -c               # Count unique occurrences
  | sort -rn              # Sort by count, highest first

    47 /missing-page.html
    23 /old-link.php
    12 /typo.html

Let's build a real-world pipeline step by step. The goal: find which missing pages cause the most 404 errors in a web server log. cat access.log reads the entire log file. It outputs every line to stdout, which flows to the next command. grep "404" filters to keep only lines containing 404 - the HTTP status code for Not Found. All other log entries are discarded. cut -d' ' -f7 extracts just the URL field. The -d sets space as the delimiter, -f7 extracts the seventh field, which in standard log format is the requested URL. sort puts the URLs in alphabetical order. This is necessary because uniq only detects adjacent duplicates. uniq -c counts consecutive identical lines, outputting the count followed by the value. Since we sorted first, identical URLs are grouped together. Finally, sort -rn sorts the counts numerically (-n) in reverse order (-r), putting the highest counts first. The result shows which missing pages are requested most often - valuable for fixing broken links or creating redirects. This pipeline combines six simple commands into powerful log analysis. Each command does one thing, and pipes orchestrate the flow.

Common Pipeline Patterns

# Filter and count
grep "pattern" file | wc -l

# Sort and deduplicate
sort file | uniq

# Search process list
ps aux | grep "httpd"

# View paginated output
cat /var/log/messages | less

# Extract and format columns
df -h | awk '{print $1, $5}'

# Find large files
du -sh * | sort -rh | head -10

# Monitor log in real-time, filtered
tail -f /var/log/messages | grep --line-buffered "error"

# Count file types in directory
find . -type f | sed 's/.*\.//' | sort | uniq -c | sort -rn

These pipeline patterns solve common system administration tasks. "grep pattern | wc -l" is the standard way to count matching lines - simpler than grep -c in complex pipelines. "sort | uniq" removes duplicates. Remember, uniq only removes adjacent duplicates, so sort must come first. The -u option to sort can do both in one command. "ps aux | grep process" searches the process list - you'll use this constantly to find running processes. Often combined with grep -v grep to exclude the grep process itself. Piping to less provides pagination for long output. View messages log, large directory listings, or command output one screen at a time. awk excels at column extraction and formatting. The df example prints just the filesystem name and usage percentage. "du -sh * | sort -rh | head -10" finds the largest items in a directory - du gets sizes, sort orders by size (human-readable numbers with -h), head shows just the top 10. For monitoring, "tail -f" follows a log file in real-time. Piped through grep, you see only matching lines as they appear. The --line-buffered flag ensures immediate output. The final example counts files by extension - a creative combination of find, sed, sort, and uniq.

The tee Command

tee reads from stdin and writes to both stdout AND one or more files simultaneously - like a T-junction in plumbing.

Command

→ stdout →

tee file.txt

→

Screen

↓ also writes to

file.txt

# Save output while also viewing it
ls -l /etc | tee etc_listing.txt

# Append instead of overwrite
echo "new entry" | tee -a logfile.txt

# Write to multiple files
command | tee file1.txt file2.txt file3.txt

# Use with sudo (common pattern)
echo "setting=value" | sudo tee /etc/config.conf

The tee command solves a common problem: what if you want to save output to a file AND see it on screen? With just redirection, you get one or the other. tee gets its name from a T-shaped pipe fitting in plumbing. Data comes in, and tee sends it two directions: to stdout (continuing down the pipeline or to the terminal) and to a file. "ls -l /etc | tee etc_listing.txt" shows the listing on your screen while simultaneously saving it to the file. You get visual feedback and a permanent record. The -a option appends rather than overwriting, just like >> versus > for redirection. tee can write to multiple files simultaneously - useful for creating backups or distributing output to several logs. A very common pattern is using tee with sudo. "echo setting | sudo tee /etc/config.conf" works because tee runs with sudo privileges and can write to protected files. The naive "sudo echo setting > /etc/file" doesn't work because the shell (not echo) handles redirection, and the shell isn't running as root. tee is the elegant solution.

The xargs Command

xargs builds and executes commands from stdin, converting input into arguments for another command.

# Delete files found by find
find /tmp -name "*.tmp" | xargs rm

# Handle filenames with spaces (-0 and -print0)
find . -name "*.log" -print0 | xargs -0 rm

# Limit arguments per command (-n)
echo "a b c d" | xargs -n 2 echo
a b
c d

# Interactive mode - confirm each command (-p)
find . -name "*.bak" | xargs -p rm

# Use placeholder for argument position (-I)
find . -name "*.txt" | xargs -I {} cp {} /backup/

# Parallel execution (-P)
find . -name "*.jpg" | xargs -P 4 -I {} convert {} -resize 50% small_{}

xargs transforms input lines into command arguments. This is essential because many commands don't read filenames from stdin - they expect arguments. Pipes send data to stdin, but commands like rm expect filenames as arguments. xargs bridges this gap. "find /tmp -name *.tmp | xargs rm" finds files and passes them to rm for deletion. Without xargs, rm would wait for stdin input rather than receiving filenames as arguments. Filenames with spaces cause problems because xargs splits on whitespace. The -print0 and -0 combination uses null characters as separators instead, safely handling any filename. The -n option limits how many arguments xargs passes at once. This is useful when commands have argument limits or when you want to process items in batches. The -p option prompts for confirmation before each command execution - a safety feature for destructive operations. The -I option (often with placeholder {}) specifies where in the command the argument should go. This enables commands where the argument isn't at the end, or appears multiple times. The -P option enables parallel execution - in the example, four convert processes run simultaneously, dramatically speeding up image processing. xargs is a powerful tool for building complex command workflows.

Practical Examples

# Log all errors from a script
./backup.sh 2>> /var/log/backup_errors.log

# Run command silently (discard all output)
cron_job.sh &> /dev/null

# Save command output with timestamp
{ echo "=== $(date) ==="; df -h; } >> disk_report.txt

# Create file requiring root, with user content
echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf

# Process files found by find
find /var/log -name "*.log" -mtime +30 | xargs -r gzip

# Compare two directories
diff <(ls dir1) <(ls dir2)

# Monitor multiple logs simultaneously
tail -f /var/log/messages /var/log/secure | grep -E "(error|fail)"

Let's examine practical redirection examples for real system administration tasks. Appending script errors to a log file (2>>) captures issues for later review without losing history. Each run adds to the log. Running scripts silently with &> /dev/null is common for cron jobs where you don't want email notifications for routine output - only let errors through if you redirect just stdout. The curly brace grouping runs multiple commands and redirects their combined output. Here, a timestamp header precedes the disk report, both going to the same file. The tee with sudo pattern lets regular users create root-owned files - essential for modifying system configuration from scripts. The find with xargs -r compresses old logs. The -r flag means don't run the command if there's no input - prevents gzip from waiting on stdin when no files match. Process substitution with <() is advanced but powerful. It treats command output as a file, so diff can compare two directory listings directly. The final example uses tail -f on multiple files, filtering through grep for errors. The -E flag enables extended regex for the "or" pattern. These examples show how redirection and pipes solve real administration challenges.

Common Mistakes

# WRONG: Redirecting to the same file you're reading
sort file.txt > file.txt          # Results in empty file!

# RIGHT: Use a temporary file or sponge
sort file.txt > temp.txt && mv temp.txt file.txt
sort file.txt | sponge file.txt   # (requires moreutils)

# WRONG: stderr redirect order
command 2>&1 > file.txt           # stderr still goes to terminal

# RIGHT: Redirect stdout first
command > file.txt 2>&1

# WRONG: Expecting pipe to modify original
cat file.txt | grep "pattern" | sort   # file.txt unchanged

# WRONG: Using redirect where pipe is needed
ls > wc -l                        # Creates file named "wc"!

# RIGHT: Use pipe
ls | wc -l

Let's address common mistakes that catch even experienced users. Redirecting output to the same file you're reading destroys the file. The shell truncates the output file BEFORE the command reads the input file. By the time sort opens file.txt, it's already empty. Always use a temporary file or the sponge utility which absorbs all input before writing. The 2>&1 redirect order mistake is subtle. "2>&1" means "send stderr where stdout is currently going." If stdout still points to the terminal when this executes, stderr goes to the terminal. Redirect stdout first, then 2>&1 sends stderr to that same destination. Pipes don't modify files. "cat file | grep pattern | sort" displays filtered, sorted content but file.txt is unchanged. If you want to modify the file, you need to redirect output to a new file and replace the original. Confusing redirect with pipe creates unexpected files. "ls > wc -l" creates a file literally named "wc" containing the ls output, then tries to run "-l" as a command. The pipe character | is what connects command output to command input. These mistakes often produce confusing results rather than clear errors, making them tricky to debug.

Quick Reference

Operator	Description
cmd > file	Redirect stdout to file (overwrite)
cmd >> file	Redirect stdout to file (append)
cmd 2> file	Redirect stderr to file
cmd 2>&1	Redirect stderr to same place as stdout
cmd &> file	Redirect both stdout and stderr to file
cmd < file	Redirect stdin from file
cmd << EOF	Here document (multi-line input)
cmd <<< "string"	Here string (single-line input)
cmd1 \| cmd2	Pipe stdout of cmd1 to stdin of cmd2
cmd \| tee file	Send output to file AND stdout

Here's your quick reference for I/O redirection operators. For output, greater-than creates or overwrites, double greater-than appends. Add the file descriptor 2 for stderr. The 2>&1 syntax merges stderr with stdout, and &> is the shorthand for redirecting both together. For input, less-than redirects from a file, double less-than starts a here document for multi-line input, and triple less-than is a here string for single-line input. The pipe connects command output to command input, and tee splits output to both a file and continued pipeline. Memorize these operators - you'll use them daily. The patterns become second nature with practice. When in doubt, remember: greater-than sends output somewhere, less-than brings input from somewhere, and pipe connects commands together. Start simple, add complexity as needed, and always test with non-destructive commands first when learning.

Key Takeaways

Three streams: stdin (0), stdout (1), stderr (2)

Output: > overwrites, >> appends, 2> for stderr

Input: < from file, << here doc, <<< here string

Pipes | connect commands; tee splits output; xargs builds arguments

Let's summarize the essential concepts of I/O redirection. Every process has three standard streams: stdin for input (file descriptor 0), stdout for normal output (1), and stderr for error messages (2). By default all connect to the terminal, but redirection changes this. For output redirection, the single greater-than creates or overwrites files, double greater-than appends safely. Add the file descriptor 2 for stderr redirection. The &> shorthand captures both streams. For input redirection, less-than provides input from a file. Here documents with << provide multi-line input in scripts, and here strings with <<< provide single-line input concisely. Pipes are the power tool - connecting stdout of one command to stdin of the next. Combined with tee to split output and xargs to build arguments, pipes enable complex data processing from simple commands.

Graded Lab

Redirect ls output to a file, then append a timestamp with echo
Run find across / and send errors to /dev/null while viewing results
Use a here document to create a multi-line configuration file
Build a pipeline to find the 10 largest files in /var
Use tee to save and display command output simultaneously

Next: Managing Local Users and Groups

I/O Redirectionin Bash

Controlling Command Input and Output

Learning Objectives

Standard Streams

stdin

stdout

stderr

Default Data Flow

Output Redirection Operators

Redirecting stdout

Redirecting stderr

Combining stdout and stderr

Input Redirection

Here Documents

Here Strings

Pipes

Building Pipelines

Common Pipeline Patterns

The tee Command

The xargs Command

Practical Examples

Common Mistakes

Quick Reference

Key Takeaways

Graded Lab

I/O Redirection
in Bash