为什么管道输出到 /dev/null 和 grep 会污染我的 bash 阵列？

Question

I have two shell scripts (Linux, #!/bin/bash ), one has some common functions in it for finding text etc., and the other making use of the common functions and doing some 'actual' work.

When examining an array variable ( oranges inside test2.sh ) to test/see if it's an array ( declare -p oranges 2>/dev/null | grep -q '^declare \-a' && printf "$fmt" "oranges is an indexed array" ), I stumbled across the fact that another array ( LINES inside test1.sh ) suddenly got " polluted " with a random number.

I cannot understand why this is happening. Anyone have an answer? It makes zero difference if you echo or printf when working with the scripts, only if you pipe errors to 2>/dev/null AND grep the output. I've cut-down the scripts to the bare essentials to show the problem. Also, the problem is easily worked around by breaking the one-liner apart and assigning the output from each piece to a variable(see test3.sh ), so I'm not stuck on script writing or further progress. I am stuck on trying to answer why the pollution of LINES happens.

test1.sh

#!/bin/bash

declare -a LINES

echo "::: DECLARE ::: Length of [LINES] is: ${#LINES[@]}, :::Content of [LINES] is: ${LINES[@]}"

test2.sh

#!/bin/bash

source ./test1.sh

declare -a oranges=()
echo "::: test2-1 ::: Length of [LINES] is: ${#LINES[@]}, :::Content of [LINES] is: ${LINES[@]}"


declare -p oranges 2>/dev/null
echo "::: test2-2 ::: Length of [LINES] is: ${#LINES[@]}, :::Content of [LINES] is: ${LINES[@]}"


declare -p oranges 2>/dev/null | grep -E -i '^declare \-a'
echo "::: test2-3 ::: Length of [LINES] is: ${#LINES[@]}, :::Content of [LINES] is: ${LINES[@]}"


declare -p oranges 2>/dev/null | grep -E -i '^declare \-a' && printf "$fmt" "oranges is an indexed array"
echo "::: test2-4 ::: Length of [LINES] is: ${#LINES[@]}, :::Content of [LINES] is: ${LINES[@]}"

declare -p LINES
declare -p oranges 2>/dev/null | grep -E -i '^declare \-a' && printf "$fmt" "oranges is an indexed array" || printf "$fmt" "oranges is not an indexed array"
echo "::: test2-5 ::: Length of [LINES] is: ${#LINES[@]}, :::Content of [LINES] is: ${LINES[@]}"


declare -p oranges 2>/dev/null
echo "::: test2-6 ::: Length of [LINES] is: ${#LINES[@]}, :::Content of [LINES] is: ${LINES[@]}"

And when run, the following output occurs:

::: DECLARE ::: Length of [LINES] is: 0, :::Content of [LINES] is: 
::: test2-1 ::: Length of [LINES] is: 0, :::Content of [LINES] is: 
declare -a oranges=()
::: test2-2 ::: Length of [LINES] is: 0, :::Content of [LINES] is: 
declare -a oranges=()
::: test2-3 ::: Length of [LINES] is: 1, :::Content of [LINES] is: 81
declare -a oranges=()
::: test2-4 ::: Length of [LINES] is: 1, :::Content of [LINES] is: 81
declare -a LINES=([0]="81")
declare -a oranges=()
::: test2-5 ::: Length of [LINES] is: 1, :::Content of [LINES] is: 81
declare -a oranges=()
::: test2-6 ::: Length of [LINES] is: 1, :::Content of [LINES] is: 81

test3.sh - the workaround

#!/bin/bash

source ./test1.sh

declare -a oranges=()
echo "::: test2-1 ::: Length of [LINES] is: ${#LINES[@]}, :::Content of [LINES] is: ${LINES[@]}"


someResult="$(declare -p oranges 2>/dev/null)"
thePattern="^declare \-a"

nextResult=`grep -E -i "$thePattern" <<< "$someResult"` || nextResult=""

if [[ -n "$nextResult" ]]
then
    echo "oranges is an indexed array"
else
    echo "oranges is NOT an indexed array"
fi

echo "::: test2-2 ::: Length of [LINES] is: ${#LINES[@]}, :::Content of [LINES] is: ${LINES[@]}"

Output from test3.sh..

$ ./test3.sh 
::: DECLARE ::: Length of [LINES] is: 0, :::Content of [LINES] is: 
::: test2-1 ::: Length of [LINES] is: 0, :::Content of [LINES] is: 
oranges is an indexed array
::: test2-2 ::: Length of [LINES] is: 0, :::Content of [LINES] is: 

Answer 1

LINES is a reserved variable populated by the shell with the number of rows that may fit in the terminal window. Use a different variable name (which isn't used by the shell; see Shell Variables ) and it'll work as expected.

As David C. Rankin mentioned in his comment, variables in all UPPER-CASE are generally reserved for the shell, which is why use of lower-case variable names is recommended.

If you have to use the name LINES for your variable for some reason, you can disable the checkwinsize option by the following command as a workaround; but that might have side-effects, and I can not guarantee that it'll always work.

shopt -u checkwinsize

Answer 2

This may explain the behaviour:

d. Non-interactive shells now react to the setting of checkwinsize and set LINES and COLUMNS after a foreground job exits.

from http://www.softpanorama.org/Scripting/Shellorama/Bash_history/bash43.shtml