Shell： Shell中while循环的陷阱, 变量实效, 无法赋值变量

在写while循环的时候，发现了一个问题，在while循环内部对变量赋值、定义变量、数组定义等等环境，在循环外面失效。

一个简单的测试脚本如下：

#!/bin/bash
echo "abc xyz" | while read line
do
    new_var=$line
done
echo new_var is null: $new_var?

执行结果证明，$new_var的结果是空值。在google上查了查，才发现问题出在管道上。加上自己的总结，特分享两个使用while循环时的陷阱。

先看看下面的内容。

while循环的写法有好几种，它的语法结构为：

while test_cmd_list; do cmd_list; done

但更经常地，while循环更多地用于读取标准输入的内容来实现循环。有以下几种写法：

写法一：使用管道传递内容，这是用的最多、但却最烂的写法

echo "abc xyz" | while read line   

do 

    ...

done

写法二：

while read line

do

    ...

done <<< "abc xyz"

写法三：从文件中读取内容

while read line

do

    ...

done </path/filename

方法四：采用进程替换

while read var

do

    ...

done < <(cmd_list)

方法五：改变标准输入

exec <filename

while read var

do

    ...

done

尽管写法有多种，但它们并不等价。

陷阱一：

方法一中使用的是管道符号，这使得while语句在子shell中执行，这意味着while语句内部设置的变量、数组、函数等在循环外部都不再生效。这正是文章开头所说的陷阱。更简单的：echo haha | a=5，在命令执行结束后，变量a的值也不再是5。其余4种写法，while语句都不在子shell中执行，因此都不会出现文章开头所说的问题。

例如，使用写法二的here string代替写法一：

#!/bin/bash
while read line
do
    new_var=$line
done <<< "abc xyz"
echo new_var is null: $new_var?

或者使用写法四的进程替换：

#!/bin/bash
while read line
do
    new_var=$line
done < <(echo "abc xyz")
echo new_var is null: $new_var?

陷阱二：

关于这几种while循环的写法，还有一点要注意：写法一和写法四传递数据的源都是一个单独的进程，它们传递的数据一被while循环读取，所有数据就丢弃了，而以实体文件作为重定向传递的数据，while读取了之后并不会丢弃。更标准一些的说法是，当标准输入是非实体文件时(如管道传递的、独立进程产生的)只供一次读取；当标准输入是直接重定向实体文件时，可供多次读取，但只要某一次读取了该文件的全部内容就无法再提供读取。

举个例子，老师让我们听写10个单词，而我记忆力比较烂，他念完10个单词时我可能只写出了3个，剩余的7个因为记不住就没法再写出来。但如果我有小抄，我就可以慢悠悠的一个一个写，写了一个还可以等一段时间再写第二个，但当我写完10个之后，小抄这种东西就应该销毁掉。

回到IO重定向上，无论什么数据资源，只要被读取完毕或者主动丢弃，那么该资源就不可再得。①对于独立进程传递的数据(管道左侧进程产生的数据、进程替换产生的数据)，它们都是”虚拟”数据，要不被一次读取完毕，要不读一部分剩余的丢弃，这是真正的一次性资源。②而实体文件重定向传递的数据，只要不是一次性被全部读取，它就是可再得资源，直到该文件数据全部读取结束，这是”伪”一次性资源。其实①是进程间通信时数据传递的现象，只不过这个问题容易被人忽略。

大多数时候，独立进程传递的数据和文件直接传递的数据并没有什么区别，但有些命令可以标记当前读取到哪个位置，使得下次该命令的读取动作可以从标记位置处恢复并继续读取，特别是这些命令用在循环中时。据我到目前的总结，这样的命令有”head -n N”和”grep -m”，经测试，tail并没有位置标记的功能，因为tail读取的是后几行，所以它必然要读取到最后一行并计算要输出的行，所以tail的性能比head要差。

说了这么多，现在终于开始验证。下面的循环中，本该head每次读取2行，但实际执行结果中总共就只读取了一次2行。

[root@xuexi ~]# i=0
[root@xuexi ~]# cat /etc/fstab | while head -n 2 ; [[ "$i" -le 3 ]];do echo $i;let ++i;done     

#
0
1
2
3

使用进程替换的结果是一样的。

[root@xuexi ~]# i=0
[root@xuexi ~]# while head -n 2; [[ "$i" -le 3 ]];do echo $i;let ++i;done < <(cat /etc/fstab)

#
0
1
2
3

但如果是直接将实体文件进行重定向传递给head，则结果和上面的不一样。

[root@xuexi ~]# i=0;while head -n 2 ; [[ "$i" -le 3 ]];do echo $i;let ++i;done < /etc/fstab

#
0
# /etc/fstab
# Created by anaconda on Thu May 11 04:17:44 2017
1
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
2
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
3
UUID=b2a70faf-aea4-4d8e-8be8-c7109ac9c8b8 /                       xfs     defaults        0 0
UUID=367d6a77-033b-4037-bbcb-416705ead095 /boot                   xfs     defaults        0 0

可以看到结果中每次读取两行并echo一次”$i”，而且每次读取的两行是不同的，后一次读取的两行是从前一次读取结束的地方开始的，这是因为head有”读取到指定行数后做上位置标记”的功能。

要确定命令、工具是否具有做位置标记的能力，只需像下面例子一样做个简单的测试。以head和sed为例，即使sed的”q”命令能让sed匹配到内容就退出，但却不做位置标记，而且数据资源使用一次就丢弃。

[root@xuexi ~]# (head -n 2;head -n 2) </etc/fstab 

#
# /etc/fstab
# Created by anaconda on Thu May 11 04:17:44 2017

[root@xuexi ~]# (sed -n /default/'{p;q}' ;sed -n /default/'{p;q}') </etc/fstab     
UUID=b2a70faf-aea4-4d8e-8be8-c7109ac9c8b8 /                       xfs     defaults        0 0

其实在实际应用过程中，这根本就不是个问题，因为搜索和处理文本数据的工具虽然不少，但绝大多数都是用一次文本就”丢”一次，几乎不可能因此而产生问题。之所以说这么多废话，主要是想说上面的5种while写法中，使用最广泛的写法一虽然最简单、方便，但其实是最烂的一种。

本文：Shell： Shell中while循环的陷阱, 变量实效, 无法赋值变量