Combining Streams (2>&1)
A very common requirement in automated scripting is to log everything — both normal output and errors — into a single log file. To do this, you tell Bash: "Send STDERR to the same place STDOUT is currently going."
The syntax is 2>&1. Read it as: "Point file descriptor 2 to wherever file descriptor 1 is currently pointing."
Order matters critically here, and it's one of the most common mistakes in shell scripting. Redirections are evaluated left to right. Redirect STDOUT to a file first, then point STDERR at STDOUT, and both streams land in the file. Reverse the order — point STDERR at STDOUT before STDOUT has been redirected — and STDERR gets pointed at wherever STDOUT was pointing at that moment, which is still the terminal. The file ends up with only STDOUT in it, and STDERR keeps printing to the screen: the opposite of what was intended, and a bug that only shows up when something actually errors.
Modern Bash (4.0+) offers a shorthand that avoids this confusion entirely: a single operator that redirects both streams to the same destination at once, with no ordering to get wrong.
Here-Documents (<<)
Sometimes you want to pass a block of multi-line text into a command within a script without creating a separate file. A Here-Document (here-doc) lets you embed that text inline. You define a delimiter word (conventionally EOF, but any word works) to mark the start and end of the block; everything between the two markers becomes the target command's STDIN. The delimiter on the closing line must appear at the very start of the line with no leading spaces — a strict rule that trips people up the first time they try to indent a here-doc inside a function or loop for readability.
A variant of the syntax exists specifically to relax that rule: it strips leading tab characters from the content, so the block can be indented to match the surrounding code. It strips only tabs, not spaces — if an editor silently converts tabs to spaces, the closing delimiter still needs to be tab-indented, and a mismatch there is a subtle, easy-to-miss source of "unexpected EOF" errors.