Pipes and Redirection

By default a bash pipeline reports only the exit status of its last command; every earlier stage's status is discarded. So false | true returns 0, and a failing build piped into tee or grep looks successful to CI.

A bare > redirects only standard output, file descriptor 1. Error messages travel on standard error, descriptor 2, which stays on the terminal until you redirect it explicitly with 2> file, 2>> file, or 2>/dev/null.

Bash applies redirections left to right, and each one copies where the target points at that moment. cmd > out.log 2>&1 puts stdout in the file and then makes stderr a copy of it, so both are captured. cmd 2>&1 > out.log copies stderr to the terminal first, then moves only stdout.

Quoting the here-document delimiter (<<'EOF') sends the body through untouched; leaving it unquoted (<<EOF) makes the local shell expand $variables, $(...) and backticks in the body first. Use the quoted form for anything that must be evaluated on the remote host.

With set -o pipefail, a bash pipeline returns the status of the rightmost command that exited non-zero, or 0 if every stage succeeded. Without it, only the last stage's status counts, so earlier failures vanish.

The inner <(find ...) expands to a /dev/fd path, and the separate outer < redirects the loop's standard input from it, so the loop itself runs in the current shell and its variable updates survive. Without the space, << starts a here-document.

The shell performs redirections before it runs sort, so > data.txt truncates the file to zero bytes first and sort then reads an empty file. Filter into a temporary file and rename it over the original instead.

A here-string expands the word after <<< and supplies it as the command's standard input with a single newline appended. Bash performs parameter and command substitution on the word but no word splitting or globbing, so an unquoted variable still arrives as one intact string.

Process substitution runs sort a.txt as a separate process and expands to a filename, typically /dev/fd/63, that reads from that process's output. diff opens that path like an ordinary file, so the two sorts stream straight into it.

Run exec 3>/var/log/deploy.log once near the top of the script. That opens the file on descriptor 3 for the whole shell, so later commands write to it with >&3 while stdout and stderr are untouched. Close it with exec 3>&- when finished.

PIPESTATUS describes only the most recently executed pipeline, and every command overwrites it — including the plain assignment rc=$?, which resets it to a single 0. Copy the whole array on the line immediately after the pipeline: statuses=("${PIPESTATUS[@]}").

Your unprivileged shell performs the redirection, opening /etc/motd as you before sudo ever runs, so the open fails. Pipe into a privileged writer instead: echo hello | sudo tee /etc/motd.

Save the current stdout on a spare descriptor first: exec 3>&1, then exec 1>run.log, and restore afterwards with exec 1>&3 3>&-. Without the saved copy the original destination is unrecoverable. Redirecting a { ...; } group instead is safer because the shell restores stdout automatically when the group ends.

Either use an unquoted delimiter and backslash-escape every literal, writing "$@", or use a quoted delimiter for a fully literal body and emit the baked-in values as separate generated assignment lines. The second survives review, because one missed backslash in the first is a silent bug.

grep exits 1 when it finds no matching lines, which is a result, not an error. pipefail promotes that 1 to the pipeline's status even though wc succeeded. Tolerate it explicitly with || true, or check the stage's status via PIPESTATUS and accept 1.

bash runs gzip as a separate asynchronous process and expands >(gzip …) to a /dev/fd path that feeds its stdin. $? reports pg_dump only — this is not a pipeline, so nothing propagates gzip's status — and the script can move on, or exit, while gzip is still writing.

Standard output is the script's data channel: whatever lands there is what a pipeline, a redirect or a command substitution captures. Putting progress messages there corrupts the caller's data, while standard error keeps them visible and independently silenceable.

The dash in <<- strips leading TAB characters only — never spaces — from both the body lines and the delimiter line. A closing line indented with spaces therefore never matches, so bash reads to end of file and swallows the rest of the script.

The background process inherited copies of the script's stdout and stderr, which are the pipes back to the ssh client. ssh keeps reading until every writer closes, so it waits on the still-running child. Redirect the child's descriptors away from those pipes when starting it: cmd >/dev/null 2>&1 </dev/null &.

141 is 128 plus 13, the status bash records for a process killed by SIGPIPE. head exits after 20 lines and closes the pipe, so the producer dies on its next write, and pipefail promotes that 141 to the whole pipeline's status.

The /dev/fd path from <(...) names a pipe, which is readable once and forward only. unzip must seek to the central directory at the end of the archive before it can read entries, and a pipe cannot be seeked; diff and grep only stream forward, so the same path suits them fine.

Prompts belong on standard error, not standard output, so they stay visible when a caller redirects the script's output to a log. Bash's read -p already prompts on stderr. /dev/tty writes straight to the controlling terminal, but fails when there is none.