A bash script must write progress lines to /var/log/deploy.log while its ordinary stdout still goes wherever the caller pointed it. How do you open a dedicated file descriptor once with exec, write to it, and close it when done?

## exec without a command `exec` has two jobs that look like one. With a command word — `exec myprog` — it replaces the shell process. With **only redirections** and no command word, it does something quite different: it applies those redirections to the running shell, permanently, and execution continues on the next line. That second form is the tool here. ```bash exec 3>/var/log/deploy.log # shell now holds the file open on fd 3 ``` Descriptor 3 is now part of the shell's descriptor table. Every command the script runs afterwards inherits it, which is exactly why `>&3` works from anywhere in the script, including inside functions and loops. ## Writing to the channel ```bash exec 3>/var/log/deploy.log log() { printf '%s %s\n' "$(date +%FT%T)" "$*" >&3; } log "deploy starting" build_artifacts # its own stdout still goes to the caller log "artifacts built" ``` `>&3` duplicates descriptor 3 onto descriptor 1 for that one command — the same duplication operator as `>&2`, just with a descriptor you opened yourself. Descriptors 1 and 2 are never touched, so the script's real output and its errors keep flowing wherever the caller sent them. That is the whole point of a third channel: three independent destinations, chosen once. ## Why open once instead of `>> file` on every line You could write `printf ... >> /var/log/deploy.log` on every log line. Opening once with `exec` is better for three reasons: 1. **One open file, one offset.** With `exec 3>file` the file is opened a single time; the shared write offset advances with each write, so successive writes append naturally without needing `>>` semantics per call. 2. **The path is resolved once.** If the script later `cd`s, or the log directory is rotated and replaced underneath it, the descriptor still refers to the file the script opened — which is a feature when you want all lines in one place, and a thing to know about when log rotation expects reopening. 3. **Less syscall churn.** Each `>> file` is an `open()` plus a `close()` around the write. Use `exec 3>>` when the file must be *appended* to across separate runs rather than truncated at startup — `exec 3>` truncates, exactly like `>` on a command. ## Closing, and why it matters ```bash exec 3>&- # close descriptor 3 ``` `n>&-` closes descriptor `n`. Two reasons to bother in a real script: - **Inheritance.** Any child process the script starts inherits every open descriptor. A background daemon that inherits fd 3 keeps the log file open long after the script exits, so the disk space is not reclaimed if the file is deleted, and a lock file held on that descriptor is never released. - **Scoped exposure.** You can close a descriptor for one command only: `some_child 3>&-` runs that child without fd 3 while the script keeps it. Bash closes everything at exit anyway, so closing is about children and long-lived state, not tidiness for its own sake. ## Read-write and other openings The same numbered-descriptor mechanism covers more than writing: ```bash exec 4</etc/hosts # open for reading on fd 4 read -r first_line <&4 exec 4>&- exec 5<>/tmp/state.txt # read-write, does NOT truncate ``` `n<> file` opens for both reading and writing without truncating — useful when a file must be updated in place, and the standard way to open a lock file that you neither want to empty nor need to write to. ## Letting bash allocate the number Hardcoding 3 through 9 is fine in a script you own end to end, but in a sourced library it can collide with a descriptor the caller already uses. Since bash 4.1: ```bash exec {log_fd}>/var/log/deploy.log printf 'started\n' >&"$log_fd" exec {log_fd}>&- ``` Bash picks a free descriptor (10 or above) and stores the number in `log_fd`. macOS ships bash 3.2, where this syntax is a parse error — one of the standard reasons a script that works on Linux fails on a Mac. ## The interview answer in one breath "`exec` with redirections and no command rewires the shell itself, so `exec 3>file` gives the script a private, long-lived output channel; commands write to it with `>&3`, it never disturbs stdout or stderr, and `exec 3>&-` closes it before I fork anything that should not inherit it."