for line in sys.stdin将数据读入数组(for line in sys.stdin)
for line in sys.stdin
纠结一个下午和一个晚上了 ,我想在syslog-ng里面添加一个program destination ,程序是用Python写的 ,结果发现file destination总是在第一时间就能收到消息 ,而program则没有什么动静 ,反复测试了好多遍都是如此 。man Python ,发现了Python有个’-u’参数 ,man是这样说的 。
-u Force stdin, stdout and stderr to be totally unbuffered. On systems where it matters, also put stdin, std-out and stderr in binary mode. Note that there is internal buffering in xreadlines(), readlines() and file-object iterators (“for line in sys.stdin ”) which is not influenced by this option. To work around this, you will want to use “sys.stdin.readline() ” inside a “while 1:” loop.
加上’-u’之后 ,标准输出打印的内容很快能进入日志文件中 ,标准输入还是没有动静 。当时没有仔细看这段说明,里面已经指出了for line in sys.stdin并不受影响 ,而我的代码偏偏是这样从标准输入里面读数据的 。后来无意中在stackoverflow发现有一个人说这样迭代方式需要等到EOF出现才会开始执行 ,如果使用sys.stdin.readline()就不会有问题,测试了下发现果然是好用的 。
下面两个例子可以说明问题 。在终端中分别运行两个程序 ,第一种遍历方式会等到敲入CRTL+D才会打印输入的内容 。第二种方式输入一行 ,回车之后就会打印这行 。
奇怪的是,我写Hadoop Streaming Job时 ,一直都用for line in sys.stdin这种方式遍历 ,也没有出过问题 。Hadoop Streaming官方文档里面的例子用的是readline这种方法。我猜这个应该是Hadoop的数据都保存在本地了 ,等于用cat的方式给脚本送数据 ,所以没有问题 。
在网上查资料的时候还发现有人反馈Python使用for line in sys.stdin的一个bug:Issue1633941 ,就是需要输入两次CRTL+D程序才会退出 。Ralph Corderoy指出这个和Python 2.6用fread导致的问题 ,大概的意思是fread读到的数据长度为0时 ,它才认为获取到了EOF。如果没有得到指定长度的数据 ,即使数据后面存在EOF ,它也会忽略 。解决办法是在循环内使用feof对stdin进行一次判断,如果结束了就立即退出 。
创心域SEO版权声明:以上内容作者已申请原创保护,未经允许不得转载,侵权必究!授权事宜、对本内容有异议或投诉,敬请联系网站管理员,我们将尽快回复您,谢谢合作!