"uptime.py" [noeol] 69L, 2311C
"system/uptime.py" 69L, 2312C

‘noeol‘ 就是 ‘no end-of-line‘, 即“没有行末结束符”

使用cat -A 命令可以看到两个文件的不同之处在于最后一行是否有换行符

 cat -A uptime.py
if __name__ == ‘__main__‘:$
    uptime = uptime()$
    print(uptime)$
root@UA4300D-spa:~/hanhuakai/pro_07/git_0709/ssapi#

 cat -A system/uptime.py
if __name__ == ‘__main__‘:$
    uptime = uptime()$
    print(uptime)root@UA4300D-spa:~/hanhuakai/pro_07/git_0709/ssapi#

linux下feff的问题

由于linux下vi无法直接写入中文注释，所以只能在windows下将写好注释的代码传到linux服务器上，但是问题也就出现了，我在 windows下用的是Notepad++这款编辑器（感觉还挺不错，有语法高亮识别）编辑源代码的，加过注释后上传到linux上无论什么语言环境 （LANG）都是乱码，然后看了一下Notepad++的设置，发现默认为ANSI格式，于是就转换为UTF-8格式编码（因为linux里有这个格式的 嘛），然后再上传到linux服务器上，linux也设为UTF-8语言环境，可以看到中文注释了！但是发现每个文件第一行都会有 “<feff>”这个字符串。google了下发现问题的所在了。

原来这是个被称作BOM(Byte Order Mark)的不可见字符，是Unicode用来标识内部编码的排列方式的，在UTF-16、UTF-32编码里它是必需的，而在UTF-8里是可选的。因 此，才会出现有的编辑器在文件头部添加添加BOM、而有的语法解析器又不作处理的的混乱情况。所谓 BOM，全称是Byte Order Mark，它是一个Unicode字符，通常出现在文本的开头，用来标识字节序 （Big/Little Endian），除此以外还可以标识编码（UTF-8/16/32），如果出现在文本中间，则解释为zero width no-break space。

这个BOM可以在编辑文本时设置的，但是，只能在第一次编辑时才能设置它为bomb还是nobomb，编辑完并保存后就无法再更改编码格式了。有关bomb命令：

#设置UTF-8编码
:set fileencoding=utf-8
#添加BOM
:set bomb
#删除BOM
:set nobomb
#查询BOM
:set bomb?

如下例子：

用vi编辑一个测试文本test.txt

查询BOM结果：（set bomb ?）

更改BOM结果：（set bomb）

保存后再次打开就会发现如下图所示：

而且我们对于上传过来的源代码没法做修改，网上有人说可以删除BOM（grep -I -r -l $‘\xEF\xBB\xBF‘ * | xargs sed -i ‘s/^\xEF\xBB\xBF//;‘），我试过了不行，不知哪位大牛指点下？检查文件中是否含BOM的命令为：

这个命令是有效的。

既然没法靠在linux下有什么命令删除BOM，那咱们只能从源头处理了，编码更改为无BOM的UTF-8编码格式。Notepad++有转换此格式的选项：

转换过后保存下然后再传到linux服务器上，问题就解决了！！

另：这个问题在sun环境和Hp环境下没有此问题，我不清楚如果忽略这个问题在编译时或程序运行时是否会产生异常，网上有人反映是有的，所以还是建议麻烦些也不要忽略此问题，谁晓得它会惹出什么麻烦呢

-- 转自  http://blog.csdn.net/lyn_bigdream/article/details/8746241