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