In bash, what does `shopt -s lastpipe` change about how a pipeline is executed, what condition must hold for it to take effect, and when would you rely on it in a production script?

## The default, and what lastpipe changes Bash normally forks a process for every stage of a pipeline. `a | b | c` is three children; the calling shell waits for them and keeps nothing they did to their own variables. That is the mechanism behind the most famous bash surprise — a `while read` loop at the end of a pipe that counts, accumulates or sets a flag, and then hands back nothing. `shopt -s lastpipe` narrows that rule by exactly one stage: the **last** command of the pipeline runs in the current shell process rather than a forked child. Earlier stages still fork — they must, since they run concurrently. So with the option set: ```bash shopt -s lastpipe n=0 printf 'a\nb\nc\n' | while read -r _; do n=$((n+1)); done echo "$n" # 3 ``` And the same option makes a bare `read` at the end of a pipeline actually populate a variable: ```bash shopt -s lastpipe printf 'hello\n' | read -r greeting echo "$greeting" # hello ``` ## The precondition: job control must be inactive This is the part candidates miss, and it is why the option looks broken when people try it. Bash documents lastpipe as taking effect only when **job control is not active**. Job control is the machinery that assigns each pipeline its own process group so it can be suspended and resumed; keeping the last stage in the shell's own process would break that model, so bash simply ignores the option when job control is on. The practical mapping: - **In a script** (a non-interactive shell), job control is off by default, so `shopt -s lastpipe` works as advertised. - **At an interactive prompt**, job control is on by default. Setting lastpipe there appears to do nothing until you also turn job control off with `set +m` — at which point you have disabled a feature you presumably want interactively. So the option is essentially a scripting feature, and testing it by pasting into your terminal will mislead you. ## Version and portability lastpipe was added in **bash 4.2**. Consequences: - `/bin/bash` on stock macOS is 3.2; `shopt -s lastpipe` there fails with an invalid-option error and a non-zero status — which, in a script running under `set -e`, aborts on the very line that was supposed to make it more convenient. - `dash`, `ash` and other POSIX shells have no `shopt` at all, so a `#!/bin/sh` script cannot use it. - If you depend on it, assert the version early rather than letting the failure surface as a mysteriously-zero counter: check `${BASH_VERSINFO[0]}` and exit with a clear message. ## Judging whether to use it The honest comparison is against the alternatives that solve the same problem locally: | Approach | Scope of change | Portability | |---|---|---| | `done < file` | one loop | any POSIX shell | | `done < <(cmd)` | one loop | bash/ksh/zsh | | `mapfile -t arr < <(cmd)` | one read | bash 4+ | | `shopt -s lastpipe` | every pipeline in the file | bash 4.2+, job control off | The first two fix the specific loop and leave the rest of the script's semantics alone. lastpipe changes what *every* pipeline in the file means, including ones written later by someone who did not notice the `shopt` at the top — and the change is invisible at the call site. That is a real maintenance cost for a saving of a few characters. Where it genuinely pays: a bash-only script whose data flows through a chain of filters — `grep | sort | awk | while read` — where restructuring into a redirect would mean either a temp file or wrapping the whole chain in a process substitution that hurts readability. There, one documented `shopt -s lastpipe` near the top, with a version guard, is defensible. ## Second-order effects worth knowing Because the last stage now runs in the calling shell, things that were harmlessly contained in a child are no longer contained: an `exit` in that stage exits the script, a `cd` in it moves the script, and a trap installed there is installed on the script. That is usually exactly what you wanted — it is the point of the option — but it means a pipeline is no longer a sandbox, and a stage written on the assumption that it was one can now change state you did not expect it to touch.