还是码云上的那个自创开源项目，思路是从服务器网页上获取纯文本后，截取最后一列（文件大小），然后与本地的文本相比较，有变化则提示之。
该网页有个特点：ISO文件名过长，长到无法全部显示，导致页面上看到的日期不全。那么用对付其它网页的那种按日期筛选的办法就会有“误判”。解决办法就是把每行链接的URL提取出来，置换掉页面上那不完整的ISO文字。这个过程没有太难的技术含量，用w3m --dump_both即可办到。只是在获取到最后一列的数字之后，“诡异”的事情发生了 --
简单描述起见，假设抓出来的最后一列只有一行吧，内容为“12345”。那么 awk '{ print $1}' 它看到的正式这个数，没问题。前面加个字符串，比如 awk '{ print “AAA"$1}'，出来的是”AAA12345"，也没异常。但是若在后面加字呢，怪事就来了！awk '{ print $1}“BBB"'，你期望出现的应该是"12345BBB”，对吧？骚年，看来你对Linux玩得还是图Young图Simple啊！它却是“BBB345” ！怎么明明加到AWK后面的，偏偏跑到前面去了 ？！这正是百思不得其解的地方 ～～
昨天的博文中，说终端不行的时候，把字符串直接给弄进文件就过关。今天一试，招法失灵、故障依旧。用各种文本编辑软件打开，文本们都好似模样俊俏的小后生，除了每行链接的<a没有严格遵照HTML语法，缺少对应的</a>标签之外，好像也是正常的。再尝试一下，既然缺少</a>，那俺就加上，用 sed 's/$/&\</a\>/g一加，乖乖，</a>倒是加进去了，可俺的语法乃指定加在行尾的啊，怎么加到行首了？由此可以百分百判断：是抓取下来的这些行有问题！
为此，在w3m命令后面，将它的各种dump参数使用了个遍。可“顽疾”怎么都请不走 ～～ 每行最后一个字符后到底发生了什么？还是祭出ghex，一看，我去～～ 0D0A，这不是巨硬家的回车换行符吗？与用nano在终端下建的随便有回车的文本相比，Linux的回车可只有 0A! 所以原因找到了，将那该死的0D0A转成0A，就能破此BUG的金身！召唤出dos2unix，秒定。
到此有些感慨：问题解决了之后，再回看原因，似乎简单得不能再简单。可当时在并不知道是这原因的情况下，真是找得好苦！所以程序员们要多多把自己落坑、爬坑的心酸史写出来，一是对所花那么长时间的一个交待；二是分享给大家，让别人不再重复自己的老路。写成的博文里面，尽量多出现曾经的故障，让搜索引擎传播出去，一找就准、一找就有收获！