Vim編辑器教程.docVIP

HYPERLINK /2006/06/17/vi_tut_1/ \o Permanent Link: Vi/Ex编辑器教程[1] Vi/Ex编辑器教程第一章 Vi基础为什么选择Vi一个贴心的编辑器。小何是个程序员，在一公司里与他人做共同维护的工作。刚从别人那里接手了一个大的模块。这个模块的代码真是满目疮痍啊，到处是修补的痕迹。而且看上去这些“意大利面条”式的代码补得不怎么牢靠；就在昨天这个模块彻底地崩溃了，使得这个部门几乎瘫痪。在一夜地奋战过后，小何终于在今早使这个模块又能运转了……在他打算出去买早餐时，该公司信息部门的副主管走过来了……“小何，这次的修复干得很好，辛苦你了。不过现在我需要这次崩溃的技术数据，要整理过的，马上。信息委员会的董事会早上召开了一个紧急会议，目的是评估问题是否在可控制的范围。如他们把矛头指向我，那我就倒大霉了。我需要有一些可以在投影机上播放的技术资料，以便转移他们的注意力。 “他们很可能会让我讲一讲日志中导致这次崩溃的错误代码的相关记录……对了，这部分内容是记录在?/oltp/err/m7?中，日志是使用追加的方式因此最新的报告会记录在文件的底部。那些人对日志中旧的部分不感兴趣，他们认为那是历史了。另外除了市郊的火车时刻表外，他们不习惯看东西是从下往上的。所以你得重新整理一下顺序。“看一下，这是日志文件： 374a12 44872 130295/074457 nonabort 5982d34 971 130295/221938 nonabort 853f7 2184 140295/102309 abort ……“恩……向他们解释第二栏的数据等于跟他们说我们早知道这些缺陷的存在，只等着模块崩溃了──那是找死。你在编辑时记得，记得将第二栏中除首尾的两个数字外的其他数字删除。“对了，他们看那些看腻了后会想仔细地看一下Lint报告的。上个月我才跟他们说我们的代码无懈可击，现在我得说服他们相信这个模块现在还在不断输出的错误消息都是些无关紧要的小毛病引起的。你得对修补后的代码进行Lint检测然后把输出结果与源文件合并。方法是先在输出的结果中找这种的信息： Line 257: obsolete operator +=然后把重要的部分放在源文件中相应行的末尾。中间用分隔符――如XXX分开，方便查找。没什么能比足量的源代码更能让会议提早结束了因为他们根本不知从何看起。“快去做吧。会议在35分钟后就开始了。” 然后我们的副主管就走了。他是暗笑着走开的，因为他已经打好算盘了――他知道在这么短的时间里没人能做好他要求的那么多的编辑任务。这样等会他就不用费力的解释这次的崩溃了，他只需把责任推给他的下属。我就跟信息委员会的人说：“我已经跟程序员说过要在9:30之前做好报告了，而且讲很清楚了。但我刚问他时他说还没弄好而且不知何时会弄好。”然后：“这些程序员就是不能意识到时刻向管理层报告进度就跟程序中的每一个字节一样重要！”不过小何在与上级的角力中并非完全落于下风，他还有秘密武器：vi将文件中的行倒置对这个编辑器而言只是小菜一碟。以下的八个按键（在以下的文章中用(ret)表示按回车键）： :g/^/m0 (ret)就能完成这个工作了。将文件中所有行的第二栏首、尾以外的其他数字删除也只要一行命令： :%s/^\([^ ]* [0-9]\)[0-9]*\([0-9] \)/\1\2 (ret)那结合Lint报告与源代码呢？就算这种工作Vi也能自动做到自动化。这条命令： :%s/Line \([0-9][0-9]*\): \(.*\)/\1s;$; XXX \2 (ret)会把Lint的报告文件改为编辑器的脚本，只要在源文件中运行此编辑器脚本就能达到我们要的编辑目的了。小何只用了几分钟，输入了几行就避免了当冤大头。他现在还剩一些时间可以考虑怎样才能防止副主管推诿责任――他可以先到街对面的咖啡厅，等在会议开始的那时再再出现在会议厅中，并用在场每个人都听得到的方式告诉副主管：“你要的那些文件就在‘斜杠?temp?斜杠?hal’文件夹中”。这篇教程的写作计划。我想写给那些对?vi/ex?有初步认识的编辑器用户。即你已经对一些类似“Vi?入门”之类的书里教的那些普通的内容已经熟悉了。这种Vi的书籍在市场上泛滥却很少触及更深层次的东西。在这系列的教程中我们会深入的探索一些较不为人知的?vi/ex?的用途。其中有不多的技巧是通过一些我们经常使用的编辑功能来实现的，但我们确很少注意到这些技巧――举例来说，用 global 命令来对处理的每一行做记号。同时我还会对关于Vi的许多常见的误区进行阐述。要做到这些，我会很详细的解释里面的每个部分。我会