Stop getting burned by subshells that swallow your variable changes

Technical Briefing | 9/9/2026

You spend twenty minutes debugging a script that just refuses to update your configuration file. You check the permissions, you check the logic, and you swear the variable is set correctly. Then you realize you piped your command into a while loop. That little pipe character just forked your process, and every variable change you made inside that loop vanished the moment the loop finished. I’ve wasted hours chasing this.

Why pipes kill your state

When you do cat file | while read line, that while loop runs in a subshell. It is a completely separate process from your main script. It gets a copy of your environment, it messes around in its own little world, and when it exits, all that work goes into the bit bucket. It is a classic trap that every shell scripter falls into at least once.

while read -r line; do count=$((count + 1)); done < file.txt; echo $count

• Redirect input from a file or process substitution to keep the loop in the current shell
• Avoid using pipes for iteration if you need to mutate variables that must survive the loop
• Use process substitution to pretend you have a pipe without the subshell tax

If you absolutely must pipe, consider writing your output to a temporary file or a named pipe instead, or rethink if the loop is even necessary. Next time your variables don’t persist, look at where you put the pipe. It is almost always the culprit.