纯真年代

阅读、体验、沉淀...

记一个 here document 的坑

2013-05-23
#程序员 #shell

1. here document

在 bash 中,here document 经常用于一些需要交互性输入指令的程序中,例如登陆 ftp。例如:

ftp -n $HOST <<EOF
quote USER $USER  
quote PASS $PASS  
binary  
put $FileName  
quit  
EOF  

2. 踩到的坑

在工作中,涉及到很多对 redis 的操作,先简单的用 shell 脚本实现了一下。大概流程是这样的:shell 脚本调用 C 语言程序,根据 C 程序的输出,来操作 redis。因此主要涉及两件事:shell 脚本获取 C 程序输出,shell 脚本用 here document 操作 redis。

(1)shell 脚本获取 C 程序输出

我需要从 C 程序中获取的是一个固定格式的字符串,通过在 C 程序中将该字符串 printf 出来,在 shell 中采用 a=$(program) 的形式即可获取这个字符串输出。

(2)获取这个字符串后,用 here document 方式,操作 redis

redis-cli -h $host_ip -p $host_port<<EOF  
set A $a  
quit  
EOF  

这个 C 程序和这个 shell 脚本运行一段时间都没出问题,直到有一天,我发现了这个 C 程序的 bug,动手修改,在调试过程中加了一些打印语句,例如 printf("XXXX"),修改后,与脚本联合调试。发现对 redis 操作不成功。操作 redis 的 here document 代码块,整体返回值 $? 都是等于 0 的,无法判断其正确与否。单独调试了下 C 程序,也没发现问题。那么问题在哪里呢?

其实上面两步都有问题:

(1)在 shell 脚本中调用 a=$(program) 后,其实 a 的值就是 program 程序运行时所有的输出。如果能保证该程序只输出一个正确的字符串,当然不会发现任何问题。可是在改代码的过程中,加了其他的 printf 语句,例如 printf("XXXX"),那么赋值后,a 的值就变成了“XXXX YYYY”,(假设YYYY是正常需要的字符串)。这种情况不光发生在添加调试用的 printf 语句时,假设程序在某个条件判断分支出错,进入 error 处理,如果要执行 printf,那么这个错误信息也会作为字符串传递给 a。

(2)在用 here document 操作 redis 时,如果上一步执行正确,例如 a 为“hello”,那么在 here document 中,执行 set A "hello",当然是不会有问题的。

可是,如果第(1)步出现问题,不管是由于加入了多余 printf 语句,还是输出了错误信息,都会把合并后的字符串传递给 a,再展开到 set A $a 中。假设 a 为“hello haha”,那么就会对 redis 执行 set A hello haha,很明显,格式不符合 redis set 命令的要求,会设置失败。如果是在 redis 的交互界面中,会显示出这一错误,但在 here document 中,并不会显示任何错误,而且在 here document 块执行完后,用 $? 来查看返回值,都会是 0。因为 shell 认为这个代码块是正确执行的。

发现这个问题是由于改了代码后,突然发现对 redis 的设置不成功了。进而一步步分析,才体会到这两个操作都后患无穷啊!