File Descriptors and Duplication

## The mechanics Every process begins with three descriptors open: 0 stdin, 1 stdout, 2 stderr. The redirection operator `n>&m` tells the shell to make descriptor `n` a duplicate of descriptor `m` — after it runs, both table entries refer to the same open terminal, file or pipe. When you leave off the number before `>`, bash supplies 1. So these two are identical: ```bash echo "boom" >&2 echo "boom" 1>&2 ``` Both mean: for this `echo` only, point fd 1 at whatever fd 2 currently refers to. `echo` is unchanged — it still calls `write()` on descriptor 1, exactly as it always does. The shell rewired the destination before `echo` ever started, and the rewiring dies with the command. The next line of the script has an untouched fd 1. Note the ampersand carefully. `echo hi >2` creates a *file called 2* in the current directory; `echo hi >&2` writes to stderr. Missing that ampersand is a common way to litter a repository with files named `2`. ## Why stdout and stderr are separated at all The split exists so a program can emit two independent things down two independent channels: - **stdout is the product.** It is what the next program in the pipeline consumes, what `$( )` captures, what `> file` archives. - **stderr is the commentary.** Progress, warnings, failures — for a human or a log, never for a parser. A script that ignores the split stops being usable as a building block: ```bash # BAD: the diagnostic rides on stdout list_hosts() { echo "warning: cache is stale" echo "web-01"; echo "web-02" } hosts=$(list_hosts) # $hosts now contains the warning as a data row ``` Send the warning to stderr and the same function composes correctly: the caller's variable holds two hostnames, and the warning is still printed on the operator's terminal. ```bash list_hosts() { echo "warning: cache is stale" >&2 echo "web-01"; echo "web-02" } ``` ## The usage-and-die idiom The canonical shape in a script that takes arguments: ```bash usage() { echo "usage: deploy <env>" >&2 exit 2 } [[ $# -eq 1 ]] || usage ``` Two things travel together: the human-readable reason on stderr, and a non-zero exit status for the machine. A caller checking `if ! deploy prod; then` learns something failed from the status; a human reading the terminal learns *what* from stderr. Printing the message with no non-zero exit is the mistake to avoid — automation cannot see text, only status. A small nuance worth knowing: `--help` explicitly requested by the user is output the user asked for, so many tools print help on stdout with status 0, and print the shorter *usage* line on stderr with a non-zero status when the invocation was wrong. ## Making it reusable A one-line helper keeps the redirection in exactly one place: ```bash log() { printf '%s %s\n' "$(date +%FT%T)" "$*" >&2; } die() { log "ERROR: $*"; exit 1; } log "starting deploy" command -v kubectl >/dev/null || die "kubectl not found" ``` Use `printf` rather than `echo` for anything with backslashes or leading dashes — `echo`'s handling of `-e` and escapes varies between bash's builtin, `/bin/echo` and other shells, while `printf` is specified. ## Sending stdout to stderr's place, not vice versa Because `>&2` is a duplication of whatever fd 2 points at, it follows the caller's redirection automatically. If the caller runs `./deploy.sh 2>> /var/log/deploy.err`, the messages land in that file with no change to the script. That is the real payoff of writing to the descriptor instead of hardcoding a path or `/dev/tty`: the script states *which channel*, and the caller decides *where*. ## What an interviewer is checking That you know `>&2` is a descriptor duplication rather than magic error syntax, that you can say why the two channels exist, and that you instinctively pair a stderr message with a non-zero exit status.