Redirection and Pipes

Every process starts with three open streams: standard input (descriptor 0), standard output (1) and standard error (2). > sends stdout to a file, replacing it, >> appends, 2> redirects errors, < feeds a file to stdin, and /dev/null discards whatever it receives. 2>&1 means "send stderr wherever stdout points now", so order matters: > all.txt 2>&1 captures both streams, while 2>&1 > file sends errors to the old stdout, such as a pipe.

A pipe, |, connects one command's stdout to the next one's stdin. A pipeline's exit status is its last command's, unless you set -o pipefail, as every deployment script should.

mkdir -p /tmp/redir && cd /tmp/redir && touch index.html
ls index.html nope.html > out.txt 2> err.txt       # the two streams go apart
cat out.txt err.txt
ls index.html nope.html 2>&1 > /dev/null | wc -l   # only stderr reaches the pipe
cut -d: -f7 /etc/passwd | sort | uniq -c | sort -rn | head -n 3
false | true; echo "without pipefail: $?"
set -o pipefail; false | true; echo "with pipefail: $?"
sudo install -m 644 /dev/null root.conf            # an empty root-owned file
sudo echo 'ServerTokens Prod' > root.conf          # fails: your shell opens the file
echo 'ServerTokens Prod' | sudo tee root.conf      # works: tee runs as root

index.html
ls: cannot access 'nope.html': No such file or directory
1
     24 /usr/sbin/nologin
      3 /bin/bash
      2 /bin/false
without pipefail: 0
with pipefail: 1
bash: root.conf: Permission denied
ServerTokens Prod

The last two lines catch everyone editing /etc: the redirection is performed by your shell before sudo starts, so it runs with your permissions. Pipe into sudo tee (or sudo tee -a to append) instead.