A bash script asks a question with `read`, but when it is run as `./setup.sh > install.log` the prompt text disappears into the log and the run looks hung. Which stream should a prompt use, and what does /dev/tty give you here?

## Why the prompt vanished A script inherits three descriptors and the caller controls all three. `./setup.sh > install.log` rewires descriptor 1 only. Anything the script wrote with `echo` or `printf` — including the question it wanted a human to answer — followed descriptor 1 into the file. Descriptor 0 is still the terminal, so `read` is genuinely waiting for input; the user just has no idea, and the run looks frozen. This is one of the most common "my CI job hangs forever" root causes. The rule that avoids it: **stdout is for the product, stderr is for the conversation with the human.** A prompt is conversation. ## What `read -p` already does Bash's `read` builtin has the right behaviour baked in. Its `-p` option displays the prompt **on standard error**, without a trailing newline, and only if input is coming from a terminal. Both halves matter: ```bash read -r -p "Delete everything? [y/N] " answer ``` Redirect stdout to a log and the prompt is still on screen. Feed the script from a pipe or a file and the prompt is suppressed entirely rather than polluting a non-interactive run. Use `-r` as a matter of habit so backslashes in the answer are taken literally. If you write your own prompt, send it to descriptor 2 explicitly and use `printf` rather than `echo` so you control the trailing newline: ```bash printf 'Continue? [y/N] ' >&2 read -r answer ``` ## `/dev/tty`: the terminal behind the redirections `/dev/tty` is a special file that always refers to the *controlling terminal* of the current process — the terminal the session is attached to, whatever descriptors 0, 1 and 2 currently point at. That makes it the last resort when even stderr has been redirected: ```bash printf 'Passphrase: ' > /dev/tty read -r -s answer < /dev/tty printf '\n' > /dev/tty ``` This is how tools like `ssh` and `sudo` manage to prompt for a password inside a pipeline. It also lets a script read a human's answer while its stdin is busy carrying data. The cost is that `/dev/tty` is not a fallback, it is a stronger requirement. A process with no controlling terminal — anything started by cron, by a systemd unit, by a container entrypoint, by a CI runner — cannot open it, and the redirection fails. Hard-coding `< /dev/tty` turns "my script asked a question nobody answered" into "my script crashed on line 12", which is arguably better, but it is still a broken automated run. ## Deciding whether to prompt at all The senior answer is to make interactivity a detected condition, not an assumption. The `test`/`[` operator `-t` reports whether a descriptor is attached to a terminal: ```bash if [ -t 0 ] && [ -t 2 ]; then read -r -p "Delete everything? [y/N] " answer < /dev/tty else answer="${FORCE_YES:-n}" fi ``` That gives one script two coherent personalities: it converses with a human at a terminal, and it takes a documented default (or a `--yes` flag, or `FORCE_YES=1`) when nobody is there. The non-interactive branch should default to the *safe* choice — declining a destructive action — so an unattended run fails closed. Two more habits round it out. `read -t 30` bounds the wait so a half-interactive environment cannot hang a pipeline forever; `read` returns a non-zero status on timeout or on end-of-file, so always branch on it rather than assuming the variable was set. And running unattended jobs with `< /dev/null` guarantees that any tool which decides to read stdin gets an immediate EOF instead of blocking — a belt-and-braces measure for third-party commands you do not control. ## Where the boundary sits The general contract is worth stating to an interviewer explicitly: a script may not assume it owns the terminal. Someone will run it from cron, pipe it into `jq`, or wrap it in a CI step, and every one of those callers is exercising a legitimate right over descriptors 0, 1 and 2. Design the interactive path as an enhancement over a fully non-interactive one, not the other way round.