事情是这样起源的:
今天用奔流下个电影,由于速度太快(都超过2MB/s了),怕被网管发现,也怕影响人家正常使用网络,我就把BT给暂停了,想看看到底下了多少,于是:

lily@LLY:~/benliud/Downloaded/Mission.Impossible.Trilogy/Mission.Impossible.1996.720P.HDVDRip.X264-TLF$ ls -lh tlf-missionimpossible1.720hdvd.mkv
-rw-r–r– 1 lily lily 4.4G 12-02 13:33 tlf-missionimpossible1.720hdvd.mkv
lily@LLY:~/benliud/Downloaded/Mission.Impossible.Trilogy/Mission.Impossible.1996.720P.HDVDRip.X264-TLF$ du -sh tlf-missionimpossible1.720hdvd.mkv
450M tlf-missionimpossible1.720hdvd.mkv

发现用ls命令看到的大小是4.4G,而du命令看到的却只有450M,于是我就纳闷了.网上找了一下原因,还是蛮好理解的,大致总结如下:
ls的大小应该是从 superblock 里面的文件描述里取的,这样的好处就是处理起来很快,不用去统计这个文件到底占用了多少block,而du命令则是 disk usage的缩写,是会去统计具体占用的block的.而这个文件下载完成以后,应该是有4.4G大的,但是目前还只下载了450M,所以文件描述里面的大小是4.4G,实际占用的确是450M.
而且,ls和du对块大小(block size)的处理,也有点不同,举例来说,如果文件只有1个字节,我们知道它也要占用一整个块,所以ls的时候的大小是1,而du的时候却会是4k.(这个4k是默认值,视所在分区文件系统的参数而定,分区的块大小可以用 tune2fs -l /dev/XXX 来查看.)
当然,ls和du都有相应的选项来改变自己的行为, ls -s 可以在第一列多显示一个实际占用的块大小(和du的值一样);du -b 也可以显示文件描述里面的大小(和ls的值一样),哈哈~

参考文章.

很多人反映不喜欢e-file依赖w3m,原因可能是觉得w3m多少有点大,其实我倒是觉得w3m蛮小巧实用的,但是对于一个百来行的脚本来说,依赖个w3m可能确实有点不太合适吧.于是一直想改成依赖curl,因为这个应该默认都有安装.
而且,Daniel老兄(我猜应该是 portagefilelist.de 的人)告诉我,portagefilelist.de 其实是支持 csv 格式输出的,这样对于我的脚本来说,简直是件天大的好事,因为省去了解析烦人的HTML了,哈哈.
于是很快就改好了新的e-file,目前已经更新至gentoo china overlay.
ChangeLog:

20081201:
去掉了w3m的依赖.

代码太长了,贴起来有些难看,呵呵.就不多此一举了,这里的代码应该马上也会更新: http://www.portagefilelist.de/index.php/Tools#e-file_.28serach_from_cmd_line.29

下载地址