Why is a variable global when set with `read variable` inside a `while` loop, but local when set with `while read variable`?

Question

unset myVariable i;
while [ -z "$i" ]; do
    read myVariable;
    echo "myVariable : '$myVariable'";
    i=foo;
done;
echo "myVariable : '$myVariable'"

(the unset is there to allow replaying the command)

press any key + ENTER, you'll get :

myVariable : '[what you typed]'
myVariable : '[what you typed]'

The value of myVariable exists outside of the while loop. Now try :

tmpFile=$(mktemp);
echo -e 'foo\nbar\nbaz' >> "$tmpFile"
while read myVariable; do
    otherVariable=whatever; 
    echo "myVariable : '$myVariable', otherVariable : '$otherVariable'";
done < "$tmpFile";
echo "myVariable : '$myVariable', otherVariable : '$otherVariable'";
rm "$tmpFile"

you'll get :

myVariable : 'foo', otherVariable : 'whatever'
myVariable : 'bar', otherVariable : 'whatever'
myVariable : 'baz', otherVariable : 'whatever'
myVariable : '', otherVariable : 'whatever'

The value of myVariable is lost when leaving the loop.

Why is there a different behaviour ? Is there a scope trick I'm not aware of ?

NB : running GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)

Answer 1

while read myVariable; do

The value of myVariable is lost when leaving the loop.

No, myVariable has the value it got from the last read. The script reads from the file, until it gets to the position after the last newline. After that, the final read call gets nothing from the file, sets myVariable to the empty string accordingly, and exits with a false value since it didn't see the delimiter (newline). Then the loop ends.

You can get a nonempty value from the final read if there's an incomplete line after the last newline:

$ printf 'abc\ndef\nxxx' | 
    { while read a; do echo "got: $a"; done; echo "end: $a"; } 
got: abc
got: def
end: xxx

Or use while read a || [ "$a" ]; do ... to handle the final line fragment within the loop body.

Answer 2

Because you're piping into the while loop, a sub shell is created to run the while loop. Now this child process has it's own copy of the environment and can't pass any variables back to its parent (as in any unix process).

In this case, the done < "$tmpFile" redirection forces bash to generate a sub-shell (as for pipe).

Quoted from bash variable scope on Stack Overflow.

Answer 3

Your second example uses a while loop that has a redirected input.

It reads using < "$tmpFile" and many shells create a sub-shell for this case. You could try to run this script with ksh93. ksh93 does not create a sub-shell in this case.

In your specific case, the reason is completely different:

• in the first example, you read one line from the input

• in the second example, you read until EOF is reached

The read command reads the input, then splits the input at IFS characters and then assigns words to the variable arguments of read.

If there are more words than variables as parameters to the read command, the last variable gets a concatenation of the rest of the words.

If there are less words than variables, the other variables are assigned an empty value.

Since you hit EOF, you have no word read but one or more variable as argument to read. This causes all variables to get an empty value assigned.

So something happened that you did not expect: EOF causes the while loop to be terminated and you see no echo command from within the while loop but only the final echo command after the while loop in this EOF case.

This final echo now prints the variable content that was cleared from hitting EOF.