不知不觉又鸽了这么久，嗨呀真是毫无愧疚感~连天数都懒得统计了呢！
昨天在做文件拆分时遇到了一个大坑，想想一定要记下来，以防以后我或者跟我遇到一样问题的小伙伴再掉进去。【不喜废话小伙伴请直接跳到结论】
事情其实很简单，我有一个总文件all.genelist，里面包含了三个物种的所有注释出来的基因家族对应的转录本号，在做分组注释时为了提高效率，我决定把三个物种的转录本号分别拆出来，也就是：A.genelist、B.genelist、C.genelist。
总文件大概长这样：
#all.genelist
Gene1 A_trans000001
Gene2 A_trans000002
...
GeneN A_trans[0-9]{6}
Gene1 B_trans000001
Gene2 B_trans000002
...
GeneN B_trans[0-9]{6}
Gene1 C_trans000001
Gene2 C_trans000002
...
GeneN C_trans[0-9]{6}
当然，真实的对应关系没有这么整齐，我恨不得它整齐一点。
不过因为物种的转录本号前缀不一样，使用grep很轻松就将它们分开了。
$ grep 'A_trans' all.genelist > A.genelist
没错，就是这么简单粗暴，由于过于简单粗暴，qiang细po心zheng的我手贱地检查了一下输入和输出文件的行数，结果粗大事了！
当时的情况是这样的：
$ wc -l ./*.genelist
326973 all.genelist
115305 A.genelist
107285 B.genelist
104384 C.genelist
如果我那不及格的高数水平够用的话，A.genelist、B.genelist、C.genelist三个输出文件的行数总和应该是326974，比all.genelist的行数326973多了一行，这是为什么呢？原文件里应该是只包含这三个物种的信息啊，再也没有多余的行了。
我的第一反应是 grep命令太过简单粗暴，拆分过程出了什么错，于是尝试用awk指令又重新拆了一遍。
$ awk '$2~/^A_trans[0-9]{6}$/{print $0}' all.genelist > A.genelist
可是结果是一样的，在wc -l后原文件依然比三个输出文件行数总和少一行，不死心的我又用sed的正则对结果进行检查，看是否有两行连在了一起被分在了一起。
$ awk '{print $2}' all.genelist | sed 's/_trans[0-9]\{6\}//g' | sort | uniq
A
B
C
输出结果证明我的第二列都是整齐的，第一列同理检查也是整齐的，那么问题来了，多出来的一行究竟在哪里呢？
我向师兄求助，师兄抛出行数出问题万金油大法：删除空行。
不对啊，是输出文件行数多了，删除什么空行？但我还是抱着试试看的态度去删了一下原文件的空行。因为这个文件是从Windows系统出品，虽然用dos2unix处理过，心里还是不踏实——结果，奇怪的事发生了。
$ grep -v '^$' all.genelist > all.filtered.genelist
$ wc -l *.genelist
326973 all.genelist
326974 all.filtered.genelist
115305 A.genelist
107285 B.genelist
104384 C.genelist
看到这个统计结果时，我整个人都凌乱了。明明执行的是删除空行操作，怎么输出的文件比原文件还多了一行？从逻辑上完全说不通。
不过，这样看来，问题倒是解决了，原来是原文件少统计了一行，我回到Windows系统用Excel打开，确认之前是统计出错了。可是为什么统计会出错？我又寄希望于师兄。
师兄：难道你也是处女座？
也？等等，师兄是不是暴露了什么……
不开玩笑了，最后经过我多方查证，本以为是dos2unix的问题，它在转换格式的过程中做了什么不可描述的事，没想到是wc -l的锅，它只以\n作为行结束符统计行数，所以最后一行如果没有\n的话会统计丢失。
Windows系统产生的文件末尾经常无\n，而是直接用了文件结束符EOF。这样文件使用Linux平台的wc统计就会少一行，这个问题不论用管道符还是dos2unix都无法解决。只有用vi编辑器或grep一类行处理命令会自动给它加上\n，所以以后，不要轻易尝试用wc -l统计Windows系统出产文件的滋味！
但对于正在学习期的我来说，这样的错误能够一次性锻炼文本处理三剑客的正则表达式，还是挺值得的，就是有点耽误课题进度。
参考资料：https://blog.csdn.net/longshenlmj/article/details/42707919
