最近Easwy在某台服务器上启动vi时,总出现vi没有响应的情况。 现象是输入vi命令后,vi窗口显示不出来,并且此时终端也没有响应,不能输入任何命令。只能用ssh再登录一个终端,在新登录终端上使用kill命令杀死此vi进程,此时运行vi的终端中显示如下信息:
*** info [lib/liblow.c(329)]: /dev/gpmctl: Interrupted system call *** err [lib/liblow.c(336)]: /dev/gpmctl: No such device or address Vim: Caught deadly signal TERM Vim: Finished. Terminated
在偶然中发现,使用putty登录这台服务器时,运行vi命令没有问题。因此怀疑和TERM环境变量的设置有关。检查putty中此环境变量:
$ echo $TERM xterm
而在vi没响应的终端里,TERM环境变量的值为:
$ echo $TERM linux
如果把TERM环境变量的值也改成xterm,那么vi可以正常启动。看来的确是TERM环境变量引起的这个问题。后来又发现,如果在linux screen中启动vim的话(此时TERM环境变量的值为screen),vim也不能正常启动。
那么为什么TERM环境变量的取值会影响vim的启动呢?经过认真排查,终于把问题定位到vimrc中的一个设置上:
set mouse=a
如果在.vimrc中设置了set mouse=a,那么在TERM环境变量为linux或screen的终端上,vi启动时就会没有反应;如果去掉这个设置,不管TERM环境变量的取值是什么,vi都能正常启动。
阅读了vim的帮助手册,手册中说,这个选项只在一些特定类型的终端上支持,比如xterm、使能了gpm的linux终端等。看来问题是出在gpm上,从上面vim被kill后的打印中也可以看出,是/dev/gpmctl设备无法访问导致vi失去反应的。
后来在vimrc中把set mouse=a一句去掉,vi终于正常了。如果有其它朋友也遇到类似的问题,不妨试一下上述解决方案。
@oldbee
应该是那台计算机的gpm有问题,具体原因没有细究。
没有遇到过楼主所说的情况,使用的vim7.3 Debian 2.6.34;
set mouse=a 一直使能;无论TERM的值是xterm, linux还是screen,都可以正常使用
尽管vim没反应,你还是可以使用ctrl+z进入background模式的,然后
$ for job in `jobs -p`; do kill -9 $job; done
不用重新登录一个新的session。
有过相同的经历,从6.X升级到7.2后也遇到了这样的问题,通过对vimrc分析和注释后,发现确实是mouse惹的祸,看vim自带的vimrc example中还说这个选项在很多地方很useful,我倒觉得这个非常evil
前一段时间我的FreeBSD上的vim也出现了同样的问题.
然后发现了vim有一个debug模式, 打开之后会把启动时各个步骤花得时间写到log里.
最后通过log调查是在term下作剪贴板相关操作时很花时间.
然后我就把那一行代码注释掉重新编译了…就好了, 一直用到现在.