As outrageously counter-intuitive as it may first appear, it is still possible to be hit by a scope bug in BASH when commands are executed in a subshell.

I was running through The Advanced Bash-Scripting Guide's "Complex Functions and Function Complexities" (a long but interesting read), and was struggling with some unexpected behaviour - a variable in my the while block of a script wasn't incrementing as expected.

curl "$THIS_URL" | sed -e "s#foo.push(##g" -e "s#}});#}}#g" > $TMP_FILE
while read line; do
  ...
done < $TMP_FILE

I found the answer here.

It turns out that this is because pipes cause Bash to perform operations within sub-shells, and variables are specific to whatever sub-shell they're called in. So, once we leave the do/while loop, $COUNTER will again evaluate to 0. Lame!

And refactored my script to use process substitution instead of pipes like this.

while read LINE; do
  ...
done < <(curl "$THIS_URL" | | sed -e "s#foo.push(##g" -e "s#}});#}}#g")

Of note is that using this hashbang at the top of the script

#!/bin/sh

failed to execute the process substitution, but replacing it with the binary it was symlinked to (/bin/bash) worked just fine.