4
7
2011
9

带补丁gvim 7.3 Arch软件包下载

准备向 Arch 迁移了,于是编译了个GVIM。之所以要自己编译,当然是要打非官方补丁了。

主要的 bug 修正为:

其中第三条只在 Arch 上出现,据说是某个库的 bug。后来折腾了段时间,发现如果 gvim 不 fork,或者 fork 后父进程生存的时间长一点点,就不会错误地出现这个提示(但是真正使用超级用户权限时也没有这个提示,不知道是否属正常情况)。


2011年7月14日更新:最新版下载地址

Category: Vim | Tags: arch C代码 linux vim
4
1
2011
3

五发行版联合发布新的发行版——The Canterbury Distribution

今天收到 arch-announce 邮件列表的消息,Arch Linux, Debian, Gentoo, Grml and openSUSE 联合发布 The Canterbury Distribution 了~~不信?那访问它们的主页试试:

PS: Arch 做了点小手脚哦~


Happy April Fool's Day!

Category: Linux | Tags: linux joke
3
28
2011
35

新的Arch,杯具的nouveau驱动

上周五,我决定在本机上安装 Archlinux,然后逐步将整个系统迁移过去。但杯具的是,三天过去了,我只能决定暂时放弃。

转向 Arch

自从 Ubuntu 9.04 发布以来,我就告别了 Windows XP,一直在用 Ubuntu 了。时至今日已经快两年了,这个系统却从来没有重装过,Ubuntu 半年一次的版本升级,我都是升级升过来的。但现在,我觉得有必要换系统了。

首先,一个系统用的时间长了,难免有些垃圾文件神马的。Linux 比 Windows 要好很多,不需要“优化大师”神马的,但不清理我心里总觉得不舒服,因为我知道系统里有那么些无用的文件存在。首当其冲的是用户配置文件,就是$HOME下的东东。很多时候会一时冲动安装一些刚刚听说的软件,后来发现并不是自己喜欢或者需要的,所以又卸载掉。最开始什么都不清楚,没有去清理掉$HOME下的配置文件。后来会手动去清理下,但还是不时地发现一些不需要的配置文件。也有一些软件安装了却没有卸载干净,像软件自己生成的全局配置文件之类的,我也不可能每次卸载软件时仔细检查 dpkg 的输出。升级软件后也可能会留下一些再也不会用到的配置文件。

其次,Ubuntu 默认装了太多我从来不用的软件。鉴别出这些软件并不容易。而 Arch 的软件除了核心系统外完全由自己指定安装,这种不干活的软件势必会少很多。另外,Arch 的软件包打包很容易。虽然我不是编译狂人,但有些软件,比如Vim,我还是一直坚持自己编译。用 Ubuntu 的话,我只能很原始地编译好再make install,卸载时还得找到configure好的Makefile来卸载,而在 Arch 上的话,我可以很容易地让 pacman 帮我管理这些自己编译的软件。

再次,我现在的 Ubuntu 不知道被我怎么折腾了下,网络连接出问题了,虽然后来解决了,但是这样会自动使用一个名为“ifupdown (eth0)”的配置,且无法更改。它唯一的问题是,其 DNS 是由路由器分配的,而不是我指定的8.8.8.8。所以每次开机后、挂起/休眠恢复后,我都需要重新连下网,等等几十秒,让我很是郁闷。另外,由于历史原因,我一直在使用 ext3 文件系统,每次检查文件系统时得等好几分钟,很想换 ext4 了。

最后,Arch 的启动和关机界面太漂亮了。我并不喜欢 Ubuntu 的图形启动界面,就像我不喜欢 Window 7 的 Aero 界面一样。纯文本的界面挺不错的,而且我知道它正在做什么。万一卡住了,我也知道是卡在什么位置了。配置也很方便,主要的系统配置都写在rc.conf里,不像 Ubuntu 下,我不知道 sshd、vsftpd 以及 privoxy 是怎么跑起来的。前两者没什么问题,可是 privoxy 我有自己运行的实例,系统自动运行反而占用了端口,让使用我自己的配置的实例运行不了。

新的系统

我是直接复制之前安装在移动硬盘上的终端版 Arch,省得升级和安装曾经安装过的软件的麻烦。首先挂载/home和/boot,dd 了个 70M 的文件再 mkfs.ext4 后挂载到 /var/lib/pacman,专门放 pacman 的数据库。之所以没有使用 reiserfs 或者 ext2,是考虑到它们可能更容易在断电或者宕机的时候出问题。安全第一啊!我可不想因为包管理器的数据库被损坏而重装系统。

复制系统我最开始用的是 tar,可是很快我发现复制过去的可执行文件的权限都是 700……果断 Ctrl-C,然后换 rsync:

rsync -aviK --delete --delete-excluded --exclude=boot/other '--exclude=var/cache/pacman/*' ./ /media/rooty

刚运行几秒钟,我突然想起了 pacman 数据库将要存放的 /var/lib/pacman.fs 文件。于是 Ctrl-C 掉,把--delete参数去掉再继续。就在我以为逃过一劫时,rsync 执行完毕,我看到最后一行赫然写着 pacman.fs 已被删除!

怎么会这样?赶紧 man 一下:

       --delete-excluded
              In addition to deleting the files on the receiving side that are not on the sending side, this tells rsync to also delete any files  on  the  receiving
              side  that are excluded (see --exclude).

In addition to

但我知道文件的数据还未真正删除,因为那个文件仍处于被挂载的状态。我尝试过 debugfs,但是没找到它。Google 过,无果。好吧,我认命,又重新 dd 了一个 pacman.fs,一边 dd 我一边祈祷,希望这个文件是连续分配的。

终于搞定复制前,我还经历过一次误删 pacman 的数据库。好在还有一份副本,所以才未酿成大祸。接下来就是一系列的 pacman 命令了。然后,当我尝试启动 gdm 时,杯具发生了——

杯具

花屏了!!!

这个图片是我手动启动 X,然后开 gnome-terminal,再在根本看不清字的情况下输入scrot而得到的。

三天来我一直在尝试各种设置,重装 nouveau 和 xorg,设定不同的 xorg.conf,但无一例外。通过 vimdiff,我注意到 Xorg.0.log 中的以下信息:

[   122.450] (--) NOUVEAU(0): Virtual size is 1366x768 (pitch 0)

而显示正确的时候(在我的 Ubuntu 和 PartedMagic 上)pitch 后面的数字都是 1408。

[    27.992] (--) NOUVEAU(0): Virtual size is 1366x768 (pitch 1408)

Google 后在这里看到设置DisplaySize等来调整 pitch 参数的方法。设置后我紧张地启动了 gdm,可希望再一次地破灭了……

昨天,我终于看到这个帖子。看来是个 bug 了。于是,再一次地,我的 Linux 系统安装宣告失败。记得2009年3月的时候,我第一次安装 Linux,也就是 Ubuntu 8.10。安装很顺利,可是在使用几天之后,X 便再也启动不了,只好重装。重装好几次,每次情况都一样,直到 9.04 的发布。

在尝试解决这个问题期间,我不仅搞定了终端下上 gtalk、中文输入(最开始是 vimim,后来改用 zhcon),还分析了 zhcon 的码表文件格式,并将 fcitx 的码表转成 zhcon 的。

如果让我重新选择,我绝对不会买使用 nvidia 显卡的机器了。

为什么我不用官方驱动

为什么我一定要用 nouveau,而不使用 nvidia 的官方驱动呢?不是因为 nouveau 开源,只是因为我转向 Arch 的原因之一——更漂亮的控制台界面。最开始我就是用的官方驱动,还有 compiz 的特效。我的控制台分辨率,从最开始的 800x600,后来终于折腾成了 1024x768。可是我的显示器是宽屏啊,1366x768 的!我忍受又胖又矮的字体好久,也忍受了每次从图形界面切换到 tty 或者另一个图形界面时的黑屏闪烁。最后,compiz 开始不给力,不时地卡好几秒。于是我终于放弃了特效,转向实用主义,用起了 nouveau 驱动。虽然 Ubuntu 的终端也就是那样,文本到处乱飞,字体也令人不爽,但毕竟切换 tty 时不再闪烁,我可以同时跑 Awesome 和 gnome 了,心里还是挺满意的。

本以为可以完美转向 Arch 的,没想到再次被 nvidia 杯具。我实在是弄不懂,开放接口文档就那么难么?


2011年4月9日更新:

今天准备试试GNOME 3 的 Live CD,结果进入图形界面后一看,和 Arch 一样的悲剧……

2011年4月11日更新:

这里有一些相关的 bug 报告——

2011年4月11日再次更新:

经过两个星期的折腾和等待,以及Update Scanner的不断监视,我于第一时间更新内核至 2.6.38.2,整个世界就正常了!

Category: Linux | Tags: arch 显卡驱动 nouveau
3
19
2011
10

Ubuntu下折腾分区后休眠不能唤醒问题的解决

我自以为把 Linux 的分区相关的东西折腾得比较熟了,所以就大胆地在本机上折腾分区,结果有一天就发现,在我在 /etc/fstab 里把 swap 区从UUID指定改成用LABEL指定之后,休眠可以成功,但唤醒失败。在开机后应当从 swap 分区恢复的时候,出现错误,然后就直接启动了,其间还毁掉了 swap 分区的内容。这么试过了两次,都失败了,于是我带着迷惑,再也没有试过了。

前天在群里看到这个链接,终于恍然大悟——原来还有个配置文件/etc/initramfs-tools/conf.d/resume!它指明了唤醒时从哪个分区恢复。当初改 swap 后我只改了fstab但没有改它,所以可以正常使用却不能唤醒。不过重新生成 initrd 时为什么没有自动更新 resume 文件呢?而且休眠时系统也不检查下resume文件,郁闷。不知道休眠时能不能指定休眠到哪个分区上呢?

resume文件的内容相当简单,就一行,像这样RESUME=LABEL=swapRESUME=后面的格式和 fstab 的第一栏一样。改了后还要sudo update-initramfs -u更新 initrd。

另外,唤醒不成功的时候我曾尝试过 s2disk 这个工具,但昨天发现,虽然它在休眠时有进度显示,可是在唤醒的时候失败了——当进度达到 100% 时就没动作了,我的桌面也就没能回来……

Category: Linux | Tags: linux ubuntu
3
16
2011
22

关于“Linux”被翻译为“你牛叉”等的一些想法

昨天,我就在我所建立的vim-cn Gtalk群上看到了在Debian官方简体中文首页将“Debian”翻译为“蝶变”、“Linux”翻译为“你牛叉”,当时还以为是某人的恶作剧。今天,又见到这篇文章,才知道真相。

最开始读的时候,看到大量的翻译破坏,我想到是不是使用的机器翻译,随后意识到不可能。又以为是Linux反对者的发泄。但我还是错了。

做这件事的人是“沈卓斌”,在多个 Wiki 上的 ID 是“jobinson99”。他除了做这些莫名其妙的翻译更改外,也做了一些妥当的翻译,让恢复变得困难起来。我在ArchLinux上的几个页面改掉了他的一些翻译,更多的翻译还得依靠Google来找出了。在改的过程中我发现部分页面有相互复制的情况。不过我没精力管了。至于维基百科,其中文社区比较强大,针对其的破坏已经被恢复。其他的Debian啊、FreeBSD啊我就没心思去管了。

有些人可能对此不太在意,但我很早就读了中文维基百科的一些方针指引之类的,很快便认定这是“破坏行为“。尽管他的这些翻译看起来是善意的,但是其行为却不会被接受。首先不说他的翻译是否准确恰当,首先一点就是——没有共识。我认为,再好的翻译,只有极少数人知道,它也不应当被作为通用或者正式的名称,不然,就像使用世界语一样,大部分人根本就不知道你在说什么,更别说搜索引擎了。哪天你有某个Linux问题,Google数日未解决,却蓦然发现,原来写有解决方案的Wiki中使用的是“你牛叉”而导致你没有找到,岂不郁闷!更何况,这些翻译多似恶搞,不是所有人都会接受的,我最开始就以为是反对者来着。

我很不明白,各开源项目的维基上尚有大量资料需要翻译,中文 man 手册既少又旧以至于我都不敢用了,wget 的中文翻译错误虽然在 Ubuntu 下已经更正了,但在 ArchLinux 下依旧存在。还有这么多可以做的,他却以为无聊的翻译可以推广开源?新手安装 Linux,谁不需要安装指导?遇到问题了,为什么可能的解决办法都是用英文写的?命令不会用,man 一下,为什么没有中文翻译?很多新手在尝试Linux时都遇到各种困难而放弃,很多老鸟都在遇到问题时苦苦挣扎,我多么希望所有的开源资料能有中文翻译!很多人说Linux难用。是啊,不会英语又没人指导就根本无法使用的系统怎么会好用呢?

至于jobinson99,我想说,如果你真的蛋疼得不行的话,就把翻译放伪基百科上去啊。


附:我在 ArchWiki 上发现的不妥翻译列表:

%s/开天辟地你牛叉/LFS/ge
%s/你牛叉龙骨/ArchLinux/ge
%s/龙骨/Arch/ge
%s/你牛叉/Linux/ge
%s/共努/GNU/ge
%s/荟萃/Wiki/ge
%s/有奔头/Ubuntu/ge
%s/蝶变/Debian/ge
%s/合成/编译/gce
%s/优盘/U盘/gce

 

Category: Linux | Tags: linux 中文支持
3
12
2011
3

果断放弃 pidgin 及解决 empathy 打开链接极度缓慢的问题

不知从什么时候起,我发现直接点击 Empathy 中的链接会花较长时间,在此期间整个 Empathy 的所有窗口皆冻结而不响应操作。次数多了之后,我注意到等待的时长和链接的响应时间有关,想到曾经在HTTP服务器看到的包含 gvfs 字样的访问记录,我想就是它了。但除了发现有一个杀死又复活的 gvfsd-http 进程之外别无收获。

昨天不知道究竟是什么原因,Empathy 经常反应迟钝,于是我终于换 pidgin 了。两天已经过去,我又换回 Empathy 了,虽然 pidgin 有很多的优点,如截图、HTML 消息、联系人手动排序、*粗体* 和 _斜体_ 支持、重新发送好友请求、XMPP 控制台、好友响应可能性预测、自动弹出消息窗口、链接识别更准确、支持富文本格式的剪贴板、可取消选择区内的表情符号、支持终端(finch)、各种未知的插件等等,但是,我依旧要换 Empathy 了,因为 pidgin 的几个非常影响我使用的 bug。一是点击对话窗口,焦点不会自动移动到输入区,虽然依旧可以输入文字,但绕过了输入法,所以必须按下 Tab 或者点下输入区,否则无法输入中文。二是输入区文本选中后会清除选择区剪贴板的内容,但并不把选中文本放到剪贴板中。其三,也是我最不能忍受的是,在它的输入框输入文本时无法使用 fcitx 的第二三码选词键。

回到 Empathy,于是又要面对它打开链接缓慢的问题。虽然改用选中再粘贴的方式也不太费事,但是,看到带有下划线的浅蓝色链接难道你就不会下意识地去点吗?

Google 了很久,没找到任何有用的东西。于是开始 strace——

strace -p `pgrep empathy` -r -f

结果用 sort + tail,很容易看到最耗时的地方。我之前还在 Vim 中手动看那近一万行的记录,真是被这些问题搞晕了头了。。。

[pid  6130]      0.000149 connect(27, {sa_family=AF_FILE, path=@"/dbus-vfs-daemon/socket-jCww54HT"}, 35) = 0
...
[pid  6130]     46.212892 recvmsg(27, {msg_name(0)=NULL, msg_iov(1)=[{"l\3\1\1\"\0\0\0\1\0\0\0G\0\0\0\4\1s\0)\0\0\0org.glib"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 122

gvfs 毫无疑问是元凶了。接收消息竟然用了 46 秒!后来我又想到去 strace gvfsd-http,最终发现真相——gvfsd-http 在 HEAD 那个 URL!真不知它想做什么。用 dpkg 查到它属于 gvfs-backends 这个软件包。看了下,依赖它的只有 deb-gview,几乎从来没用过的东西。于是果断卸载之。

卸载完后,回过头把 gvfsd-http 杀掉,终于敢放心大胆地点击 Empathy 中的链接了。

Category: Linux | Tags: Empathy linux
3
4
2011
4

Python3.2mu 与 Vim

曾经,我辛苦两星期自以为终于弄好了 Vim 的 +python3 特性,却未曾想到,编译新发布的安装 Python3.2 后 Vim 的 Python3 支持再次悲剧……

事情是这样的。在vim-cn群有人编译 Python3.2 出错问我。我于是把之前为尝新鲜而 make 的 Python3.2 又 make install 了。然后 ./configure 时就出问题了。具体错误不记得了,反正是找不到什么文件。后来我找出了我以前写的一个从 C 调用 Python 代码的小程序,编译通过,链接时找不到某些符号。折腾了好久,才知道是 Python3.2 的安装出错了,./configure 时要加 --enable-shared 参数。当然,我还比较习惯加上 --with-wide-unicode 参数。

于是我的 C 小程序编译运行成功。但 Vim 的依旧悲剧。看了 src/configure.in,注意到它并没有使用 pkg-config,而是按以前 Python 的头文件和库文件的规律硬编码进去的。这时我才发现 Python 的相关文件/目录都多了个 mu 后缀:

>>> pkg-config --cflags --libs python-3.2
-I/usr/local/include/python3.2mu  -L/usr/local/lib -lpython3.2mu
>>> ls -li /usr/local/bin/python*
163890 -rwxr-xr-x 3 root root 10877 2011-03-01 23:16 /usr/local/bin/python3
163890 -rwxr-xr-x 3 root root 10877 2011-03-01 23:16 /usr/local/bin/python3.2
164216 lrwxrwxrwx 1 root root    18 2011-03-01 23:18 /usr/local/bin/python3.2-config -> python3.2mu-config
163890 -rwxr-xr-x 3 root root 10877 2011-03-01 23:16 /usr/local/bin/python3.2mu
164107 -rwxr-xr-x 1 root root  1827 2011-03-01 23:18 /usr/local/bin/python3.2mu-config
164252 lrwxrwxrwx 1 root root    16 2011-03-01 23:18 /usr/local/bin/python3-config -> python3.2-config

这个 mu 后缀是什么意思呢?搜了半天,终于找到了:m 是普通版,u 是宽字符版(--with-wide-unicode),还有个 d 表示使用了 --with-pydebug 参数编译的。加了这些后缀,于是 Vim 配置脚本的硬编码就失败了。(它为什么要硬编码呢……T.T)对于 mu 版,修改方法是这样的:

# For Python3.2
if which python3 >/dev/null 2>&1 && [ $(python3 -c 'import sys; print(sys.version_info.minor)') -ge 2 ]; then
  sed -i -e 's|-lpython${vi_cv_var_python3_version}[dmu]*|-lpython${vi_cv_var_python3_version}mu|' \
         -e 's|python${vi_cv_var_python3_version}/config[^"]*|python${vi_cv_var_python3_version}/config-3.2mu|' \
         -e 's|include/python${vi_cv_var_python3_version}[dmu]*|include/python${vi_cv_var_python3_version}mu|' \
    src/configure.in
  # Fixed: no longer needed.
  # sed -i -e 's|PyEval_InitThreads();|/* PyEval_InitThreads(); */|' \
  #   src/if_python3.c
  autoconf=1
fi

[ $autoconf -eq 1 ] && (cd src && autoconf)

后面那个对 src/if_python3.c 的修改我也不知道是为什么,反正不这样的话调用 Python 时就 SIGABRT 出错退出,而这样改了之后好像也没什么负面影响。至于找出这个语句的办法嘛,当然是不知比 jdb 好用多少倍的 gdb 啰。


2011年4月19日更新修正了 Python3 接口的内存泄漏问题,发现已不再需要删掉那句代码了(删掉后反而出错)。

Category: python | Tags: python vim 编译
2
27
2011
9

Wine QQ隐私保护器

鉴于QQ 4 Linux实在太不好用,有些不得不使用QQ的Linux用户使用Wine来运行QQ,我经过努力也成功了,但依旧不用,因为在去年的3Q大战中我们看到腾讯实在难以信任。想想我的ssh密钥、GPG密钥、getmail和msmtp的配置文件等等非常重要的文件QQ皆可轻易扫描并上传……

想过使用另外的低权限用户来wine QQ。然而即使这样,我自己的众多文件QQ依然可以看到,心中还是不安,而且这样作为QQ的重要功能之一——互传文件——将很不方便。于是终于有一天,我开始折腾chroot了。为了不需要总是sudo,我用C写的,可以使用Linux的suid特性,同时也练习下C编程。在man相关系统调用的时候,我还发现了unshare这个调用,竟然可以把挂载的文件系统设置成只在新的挂载命名空间(mount namespace)中可见。这样就可以把为了chroot而mount --bind的项目全部隐藏起来,免得mount输出一大堆不想看到的东西。至于umount嘛,不管了,反正只是mount --bind的。

/* ===================================================================== *
 * chrooted wine QQ
 * ===================================================================== */
#define _GNU_SOURCE
#include<unistd.h>
#include<sys/stat.h>
#include<sys/types.h>
#include<sys/mount.h>
#include<linux/limits.h>
#include<sched.h>
#include<stdio.h>
#include<stdlib.h>
#include<string.h>
#include<errno.h>
#define ROOT "/tmp/.rwine"
#define PROGRAM "你的QQ的目录"
/* 文件共享目录;若不存在会自动创建 */
#define SHAREDIR "哪个目录作为共享?"
#define BIN "Bin/QQ.exe"
#define ROOTD(dir) ROOT dir
#define MKDIR(dir) mkdir(ROOTD(dir), 0777)
#define MOUNTBIND(dir) mountbind(dir, ROOTD(dir))
int mountbind(const char *source, const char *target);
/* --------------------------------------------------------------------- */
int main(int argc, char **argv){
  int ret;
  ret = unshare(CLONE_NEWNS);
  if(ret){
    perror("unshare");
    exit(1);
  }
  seteuid(getuid());
  ret = mkdir(ROOT, 0777);
  seteuid(0);
  if(ret && errno != EEXIST){
    perror("mkdir new root dir");
    exit(1);
  }

  seteuid(getuid());
  mkdir(SHAREDIR, 0700);
  seteuid(0);
  setgid(0);
  MKDIR("/lib");
  MKDIR("/usr");
  MKDIR("/usr/share");
  MKDIR("/usr/bin");
  MKDIR("/usr/lib");
  MKDIR("/etc");
  MKDIR("/etc/fonts");
  MKDIR("/program");
  MKDIR("/dev");
  MKDIR("/tmp");
  MKDIR("/tmp/share");
  chmod(ROOTD("/tmp"), 01777);

  ret = MOUNTBIND("/lib")
    || MOUNTBIND("/usr/share")
    || MOUNTBIND("/usr/bin")
    || MOUNTBIND("/usr/lib")
    || MOUNTBIND("/etc/fonts")
    || MOUNTBIND("/dev")
    || mountbind(PROGRAM, ROOTD("/program"))
    || mountbind(SHAREDIR, ROOTD("/tmp/share"));
  if(ret){
    perror("mount --bind");
    exit(1);
  }

  char path[PATH_MAX];
  char path2[PATH_MAX];
  char *p;
  strcpy(path, getenv("HOME"));
  strcat(path, "/.wine");
  strcpy(path2, ROOT);
  p = strtok(path, "/");
  seteuid(getuid());
  while(p){
    strcat(path2, "/");
    strcat(path2, p);
    mkdir(path2, 0777);
    p = strtok(NULL, "/");
  }
  seteuid(0);
  /* path changed by strtok */
  strcpy(path, getenv("HOME"));
  strcat(path, "/.wine");
  strcpy(path2, ROOT);
  strcat(path2, path);
  ret = mountbind(path, path2);
  if(ret){
    perror("mount --bind user's wine dir");
    exit(1);
  }
  strcpy(path, getenv("HOME"));
  strcat(path, "/.fonts");
  if(access(path, X_OK) == 0){
    strcpy(path2, ROOT);
    strcat(path2, path);
    seteuid(getuid());
    mkdir(path2, 0777);
    seteuid(0);
    ret = mountbind(path, path2);
    if(ret){
      perror("mount --bind user's font dir");
      exit(1);
    }
  }
  strcpy(path, getenv("HOME"));
  strcat(path, "/.fontconfig");
  if(access(path, X_OK) == 0){
    strcpy(path2, ROOT);
    strcat(path2, path);
    seteuid(getuid());
    mkdir(path2, 0777);
    seteuid(0);
    ret = mountbind(path, path2);
    if(ret){
      perror("mount --bind user's fontconfig dir");
      exit(1);
    }
  }

  ret = chroot(ROOT);
  if(ret){
    perror("chroot");
    exit(1);
  }
  chdir("/tmp");
  ret = setuid(getuid());
  if(ret){
    perror("setuid");
    exit(1);
  }
  execl("/usr/bin/wine", "/usr/bin/wine", "/program/"BIN, NULL);
  /* execl("/usr/bin/wine", "/usr/bin/wine", "notepad", NULL); */
  perror("execl");
  return 1;
}
int mountbind(const char *source, const char *target){
  return mount(source, target, NULL, MS_BIND | MS_NOSUID, NULL);
}
/* ===================================================================== *
 * vim modeline                                                          *
 * vim:se fdm=expr foldexpr=getline(v\:lnum)=~'^\\S.*{'?'>1'\:1:         *
 * ===================================================================== */

程序名为rwine。这里的“r”可不是rsync或者rcp中的“r”,而是“rbash”、“rzsh”、“rvim”中的“r”的意思。在代码的最开头有几个宏是用来配置路径的。suid程序嘛,像这种东西还是硬编码进去好了。因为只是自己使用,所以没有做太多的错误检查之类的,健壮性应该不怎么样。对于这个程序我只要没有安全漏洞就OK了。

另外说个小插曲。在调试这段代码的时候,我发现用户的路径总是挂载得不对,检查了好久,才注意到strtok的声明是

char *strtok(char *str, const char *delim);

第一个参数那里没有const!再仔细看看man文档,果然,它把传进去的参数给改了。

Category: Linux | Tags: C代码 linux QQ 腾讯
2
24
2011
10

让Vim的Align插件记住常用的对齐方式

今读到 LinuxToy 上介绍Tabular的文章,不由得又折腾了下功能更加强大的Align插件。这个插件我装了很久了,也曾读过它的文档,但是实际用得却并不多,原因除了我一般写的时候就对齐好了之外,还有一点很重要——要让它精确地按照自己所希望的方式对齐一些文本可以,但得敲好长的命令,而且还需要思考,比如对齐CSS样式声明:Align! WP0p1l: :\@<=

于是我就想,能不能把常用的对齐指令都以某种方式记录下来,需要时再调用。我首先想到的是映射或者命令。实际上Align自带了一个 AlignMapsPlugin.vim,其中就定义了很多常见的映射,但是不太容易记忆,而且不知道怎么添加。每种对齐方式定义个命令有点麻烦,于是就考虑用一个命令加参数的办法,于是就写了以下函数:

function Lilydjwg_Align(type) range
  try
    let pat = g:Myalign_def[a:type]
  catch /^Vim\%((\a\+)\)\=:E716/
    echohl ErrorMsg
    echo "对齐方式" . a:type . "没有定义"
    echohl None
    return
  endtry
  call Align#AlignPush()
  call Align#AlignCtrl(pat[0])
  if len(pat) == 3
    call Align#AlignCtrl(pat[2])
  endif
  exe a:firstline.','.a:lastline."call Align#Align(0, '". pat[1] ."')"
  call Align#AlignPop()
endfunction

其中对齐样式的定义是这样子的:

let g:Myalign_def = {
      \   'css': ['WP0p1l:', ':\@<=', 'v \v^\s*/\*|\{|\}'],
      \ }

Myalign_def的值是一个列表,各项分别是对齐方式的控制序列、分隔符正则、可选的用于筛选选区的控制序列。

想到以后定义的对齐方式多了之后,那些自定义的名字会有些不记得,于是补全函数不可少:

function Lilydjwg_Align_complete(ArgLead, CmdLine, CursorPos)
  return keys(g:Myalign_def)
endfunction

现在函数和变量定义都有了,可以定义命令了:

command -nargs=1 -range -complete=customlist,Lilydjwg_Align_complete
      \ LA <line1>,<line2>call Lilydjwg_Align("<args>")

用的时候只要选中需要对齐的文本,然后按:LA 已定义的对齐方式名即可。


PS: Align 的中文对齐速度很慢,而且还有移动光标位置等“不良行为”,因此 patch 之:

--- autoload/Align.vim
+++ autoload/Align.vim
@@ -984,6 +984,11 @@
 "           nonzero value.  Solution from Nicolai Weibull, vim docs
 "           (:help strlen()), Tony Mechelynck, and my own invention.
 fun! s:Strlen(x)
+  " lilydjwg: vim7.3 有 strwidth 函数
+  if exists('*strwidth')
+       return strwidth(a:x)
+  endif
+
 "  call Dfunc("s:Strlen(x<".a:x.">")
   if g:Align_xstrlen == 1
    " number of codepoints (Latin a + combining circumflex is two codepoints)
@@ -1006,6 +1011,8 @@
    call setline(line("."),a:x)
    let ret= virtcol("$") - 1
    d
+   " lilydjwg: 这样才不会让光标乱跑
+   normal k
    let &l:mod= modkeep

 

Category: Vim | Tags: vim
2
22
2011
3

Vim7.3 的 Python3 支持修正补丁

Vim 7.3 增加了对 Python3 的支持,但其有不少 bug,从不能正确地向缓冲区中添加中文文本,到 buffer 对象不支持 slice 操作,vim.error 不是 BaseException 的子类而是一个 str,以及各种中文乱码/UnicodeDecodeError,让我这个 Python3 的坚定支持者非常郁闷,于是趁假期把 Vim 好好修理了一番。

此次修正历时两周,涉及 src/if_{py_both.h,python.c,python3.c},共 3 files changed, 308 insertions(+), 265 deletions(-),修正的具体项目为

  • 向缓冲区添加文本时正确处理编码
  • buffer 对象支持 slice 赋值
  • vim.error 不再是字符串
  • py3file 让 Python 检测文件编码
  • 向 Python 传递缓冲区字符串时使用正确的编码(这解决了 gundo 在非 UTF-8 编码时的解码出错)
  • py3 命令输入使用 'encoding' 解码后再以 UTF-8 编码(这解决了在 'encoding' 非 UTF-8 时含中文的 py3 命令的 SyntaxError)
  • 向标准输出写文本时使用正确的编码(这样 print() 之类不会输出乱码)

以上数据要感谢git工具。

目前我在 Ubuntu Linux 10.10 32bit 和 Windows XP SP3 (使用 MinGW 编译)上测试没有问题,有兴趣的请帮忙再测试下。下载地址

另外,附上 gundo 的 Python 2 & 3 兼容版以及使用 Python3 支持的 Python 补全插件 python3complete.vim(放到 ~/.vim/autoload 下)。


PS:Python3.2 发布了,增加了一些很好的新特性,比如argparse模块,str.format_map方法等等。


2011年3月3日更新:给 Vim 编译 Python3.2 支持也有些艰难,参见这篇文章

2011年4月19日更新:今天解决了内存泄漏的问题,补丁已更新。另外,本补丁将在陈列室维护。

2011年6月19日更新:此补丁已被官方采纳。

Category: Vim | Tags: C代码 python vim

部分静态文件存储由又拍云存储提供。 | Theme: Aeros 2.0 by TheBuckmaker.com