Bash脚本递归调用时循环提前终止及终端显示异常排查

问题1：递归调用导致循环提前终止的原因 #

你的循环只执行一次就终止，核心原因是递归调用的脚本继承了外层循环的标准输入（stdin）。

当你用while read line; do ... done < temp_links.txt时，整个循环的stdin是绑定到temp_links.txt的。而当你在循环里调用wiki_txt_script.sh -w $line时，这个子进程会默认继承父进程的stdin——也就是temp_links.txt。如果你的递归脚本里有读取stdin的逻辑（比如提示用户输入的交互环节），它会直接读取temp_links.txt里剩下的所有行，把输入流彻底读完，导致外层循环的read命令再也读不到内容，自然就提前终止了。

解决方法

给递归调用的脚本重定向stdin到/dev/null，让它不要占用外层循环的输入流：

while read line; do
  echo "$line"
  wiki_txt_script.sh -w "$line" < /dev/null
  echo "finished a recursive call"
done < temp_links.txt

这样递归脚本的stdin就变成了空设备，不会去读取temp_links.txt的内容，外层循环就能正常逐行处理所有URL了。

问题2：使用/dev/null后终端输出异常的原因 #

你遇到的“每行输出从上次末尾开始、后续命令也受影响”的问题，本质是终端的TTY模式被脚本中的命令（比如wget）修改后没有恢复。

有些命令（比如wget在交互模式下，或者某些需要处理终端输入的工具）会临时修改终端设置，比如关闭自动换行、禁用echo功能，或者切换到原始模式（raw mode）。正常情况下，命令执行完会自动恢复这些设置，但如果脚本在递归调用时因为stdin被重定向到/dev/null，导致命令的终端处理逻辑异常，或者脚本意外退出，就会导致终端设置没有被还原，从而出现输出不换行、输入不回显等奇怪现象。

解决方法

你可以在脚本里添加终端恢复的逻辑，确保无论脚本执行成功还是失败，都能把终端恢复到正常状态：

1. 在脚本开头保存当前终端设置，并设置退出陷阱：

# 保存当前终端的原始设置
original_stty=$(stty -g)
# 脚本退出时强制恢复终端设置
trap 'stty "$original_stty"' EXIT

2. 如果已经出现终端异常，不用重启会话，直接在终端执行stty sane命令，就能强制恢复终端到默认状态。

内容的提问来源于stack exchange，提问作者L Lansing