In a bash script, `count=0; find . -name '*.log' | while read -r f; do count=$((count+1)); done; echo "$count"` prints 0 no matter how many files matched. Why is the count lost, and what are the two standard ways to restructure the loop so it survives?

## The symptom ```bash count=0 printf 'a\nb\nc\n' | while read -r line; do count=$((count + 1)) done echo "$count" # prints 0 ``` Add an `echo "in loop: $count"` inside the body and you will see it climb to 3 — so the loop definitely ran, and the increment definitely worked. The value simply does not exist any more by the time the last line executes. This is the single most reported "bash is broken" bug, and interviewers use it because the code looks obviously correct. ## Why the value does not come back Every stage of a bash pipeline runs as its own process. In `printf ... | while ... done`, `printf` is one process and the *entire* `while` compound command is another: bash forks a subshell for it, wires up the pipe, and waits for both. A forked shell starts as a copy of the parent's variables, which is why `count` is visible *going in*. But the two processes have separate memory. The child raises its own `count` to 3, then exits; the parent's copy is still 0. There is no channel by which a child shell hands variables back to its parent — that is a property of processes, not of `while`. (The precise rules about what a subshell copies, and which other constructs create one, are a topic of their own; for loops the fact you need is simply that a pipe puts the loop in a child.) Nothing about this is specific to counters. Everything the body changes is lost the same way: array elements you appended, a flag you set, an `exit` status you stored, even a `cd`. The mirror-image bug is `printf 'x\n' | read var` — `var` is empty afterwards for exactly the same reason. ## Fix 1 — redirect the loop instead of piping into it When the data is already in a file, never pipe it: ```bash count=0 while IFS= read -r line; do count=$((count + 1)) done < list.txt echo "$count" # correct ``` The `< list.txt` attaches to the whole compound command, and no pipeline is created, so the loop runs in the current shell. ## Fix 2 — process substitution when the data comes from a command `<(cmd)` gives you a filename you can redirect from, which converts "command output" into the shape fix 1 wants: ```bash count=0 while IFS= read -r f; do count=$((count + 1)) done < <(find . -name '*.log') echo "$count" # correct ``` Mind the space in `< <(` — `<<(` is a syntax error. Process substitution is a bash extension, not POSIX; how it is implemented is its own topic. Note the ordering trade-off: the loop now runs in the current shell, but `find` runs in the background, so its exit status is not directly visible. ## Two more options `mapfile -t lines < <(cmd)` (bash 4.0+, also spelled `readarray`) reads the whole stream into an array in the current shell, after which you loop over the array with no subshell anywhere. It is the cleanest choice when the data fits in memory. `shopt -s lastpipe` (bash 4.2+) changes the rule so the *last* stage of a pipeline runs in the current shell — which would make the original code work. It applies only when job control is off, which is the default in scripts but not at an interactive prompt, so a snippet that works when pasted into a script may behave differently when pasted into a terminal. Because of that split behaviour most style guides prefer the redirect or process-substitution forms. ## Recognising it in review The tell is: a pipeline whose last stage is a `while`, `for`, `until` or `{ ... }` block that assigns to a variable used *after* the block. ShellCheck flags exactly this pair — `SC2030` on the assignment ("modification of count is local to the subshell") and `SC2031` on the later use. If the loop body only *prints* and never assigns, the pipe is harmless and you can leave it alone.