2012年5月28日星期一

libgail加载错误

在Ubuntu 12.04下面,运行GTK或者PyGTK程序都会出现如下错误:
Gtk-Message: Failed to load module "gail"

** (ancestry.py:8295): WARNING **: (../../atk-adaptor/bridge.c:793):adaptor_init: runtime check failed: (root)
这篇文章提到类似的错误,原因是32位加载了64位的libgail库。电脑上安装的libgail.so文件只有32位的:
$ locate libgail.so
/usr/lib/i386-linux-gnu/gtk-2.0/modules/libgail.so
$ file `locate libgail.so`
/usr/lib/i386-linux-gnu/gtk-2.0/modules/libgail.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=0xaa9af3bc0239d5c04771d390b3e9ea1fe4277d03, stripped
找到对应的包:
$ dpkg -S /usr/lib/i386-linux-gnu/gtk-2.0/modules/libgail.so
libgail-common:i386: /usr/lib/i386-linux-gnu/gtk-2.0/modules/libgail.so
在Synaptic(Aptitude处理multiarch有bug)里面libgail-common有两个:libgail-common:i386libgail-common,后面这个是64位的,安装上后文章开始的错误便消失了。

2012年5月27日星期日

换行符和BOM引起的麻烦

最近整理电脑里的Python程序,有一个程序运行时出错:
$ ./absent.py
./absent.py: line 1: $'\357\273\277#!': command not found
./absent.py: line 4: $'\r': command not found
然后鼠标箭头变成了一个十字。如果如下:
$ python absent.py
用Python命令来执行是好的。这个文件的前5行如下:
#! /usr/bin/env python
# -*- encoding: utf-8 -*-
# 设置不同的文字屏保,2008年6月5日

import gtk
那个十字以前就碰到过,是用./执行时程序被当成了Shell脚本,所以Python的import gtk语句被当成ImageMagick的import工具来执行了,那个十字形鼠标箭头是import用来选取截图窗口的。

这个文件是我在原单位办公室的Windows电脑下创建的,所以马上意识到是换行符引起的。Linux下的换行符是\n,而Windows下创建的文件换行符是\r\n,所以第一行其实是这样的内容:
#! /usr/bin/env python\r\n
在Linux下,系统只把\n识别为换行符,把python\r连起来识别了。我创建了一个测试程序dos.py
#! /usr/bin/env python
# -*- encoding: utf-8 -*-

import this
然后在Shell下用
sed -i 's/$/^M/g' dos.py
把换行符转成Windows下的\r\n。^M是用Control-V和Control-M打出来的。这个文件执行出错:
$ ./dos.py
: No such file or directory
当然,用Python命令来解释是好的。上面的错误可以在Shell下用等同的命令复现:
$ /usr/bin/env python^M
: No such file or directory
如果真的有python^M这个命令会呢?在~/bin目录里创建到Python解释器的链接:
ln -s /usr/bin/python python^M
~/bin目录在路径的前面,这样python^M命令可以找到了。再执行一次就好了:
 $ ./dos.py
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
......
 其实不要用env,直接在Shebang里面指定执行文件:
#! /home/tux/bin/python
# -*- encoding: utf-8 -*-

import this
出错会更直观:
$ ./dos.py
bash: ./dos.py: /home/tux/bin/python^M: bad interpreter: No such file or directory
~/bin里面创建名为python^M的链接后,就又可以执行了。再回到开始的错误:
$ ./absent.py
./absent.py: line 1: $'\357\273\277#!': command not found
./absent.py: line 4: $'\r': command not found
这个错误和上面dos.py的不同,这'\357\273\277#!'是哪里来的呢?把absent.py文件这样打开:
$ cat -e absent.py
M-oM-;M-?#! /usr/bin/env python^M$
# -*- encoding: utf-8 -*-^M$
# M-hM-.M->M-gM-=M-.M-dM-8M-^MM-eM-^PM-^LM-gM-^ZM-^DM-fM-^VM-^GM-eM--M-^WM-eM-1M-^OM-dM-?M-^]M-oM-<M-^L2008M-eM-9M-46M-fM-^\M-^H5M-fM-^WM-%^M$
^M$
import gtk^M$
原来在#!之前还有几个字符,用bvi打开:
00000000  EF BB BF 23 21 20 2F 75 73 72 2F 62 69 6E 2F 65 ...#! /usr/bin/e
00000010  6E 76 20 70 79 74 68 6F 6E 0D 0A 23 20 2D 2A 2D nv python..# -*-
它们是0xEF, 0xBB0xBF。原来这个文件是用微软的Notepad创建的,在文件头被自动加上了UTF-8的Byte Order Mark。用cat -e absent.py打开时,在#!前面显示的是M-oM-;M-?,这是指EE BB BF是把'o', ';''?'的高位设为1,可以如下验证:
>>> print ' '.join('%X' % (ord(b) + 128) for b in 'o;?')
EF BB BF
要解决问题,必须把前三个字节删除掉,并把换行转换为Unix格式的\n才能用./absent.py正确执行程序。

2012年5月13日星期日

Python和Bash的混合

上面的图片是我写的一个粗糙的Python脚本的一部分,功能是文本处理,这不是要说的,重点要说的是第30、35、54和55行。

30行是把src字符串所指的zip文件解压缩到tmpdir目录。Python有zip文件处理的模块zipfile,但是只是解压缩有点麻烦,就用Shell下的unzip工具搞定了。

54行是截取othersrc文件的一段,这个用Python的文件处理其实更自然,但是在写脚本前面已经用过现成的Bash命令了,所以就懒得再写Python,直接把Bash命令抄过来。

55行是比较文件的,这个想也没想就用Shell下的diff命令搞定了。

35行计算文件的MD5校验和,这个首先想到的应该是Shell命令,但是Shell下md5sum命令计算出来的结果还得截取字段才能得到,而Python的hashlib直接得到校验和也很简单,就用Python来完成。

上面的例子是在Python里面混合进Bash语句。我又想到一个Bash里面用Python的实例:
第49行用Python开了一个临时的HTTP服务。

这样一会儿Python,一会儿Bash的做法,我以前觉得挺别扭的,会觉得不够纯洁。可是现实情况往往是这样的:很多问题写脚本,用Bash或者 Python都可以完成,但是应该有一个最佳的办法;对脚本里面的单一功能,也是一样的,Bash或者Python的实现总有一个更好的,比如更快实现、 更简洁、已有现成的等等。现在我觉得,更加重要的是完成事情,而不是所谓的“纯洁性”,什么好用就用什么。再说,初看开头的图片,也没觉得因为Python和Bash的混合而变得很乱吧,呵呵。

2012年4月11日星期三

Firefox不能打开mailto链接

本来设置的Firefox用Gmail打开mailto链接,但最近无效了,改成用Thunderbird打开也没反应。在about:config里面搜索mailto,看到几个非默认的设置,试着把network.protocol-handler.external.mailtofalse重置回true后好了。原来这个设置决定该协议是否由外部程序打开。

2012年3月27日星期二

AutoProxy与SOCKS代理DNS

Firefox的network.proxy.socks_remote_dns选项可设置在使用SOCKS5代理的时候,DNS解析是在本地设置的服务器上还是在SOCKS代理服务器上。用AutoProxy时,对Twitter这样DNS被污染的网站,按理说socks_remote_dns必须为真才能打开。可是在about:config里面把这个选项关掉后,Twitter还是能打开。

后来怀疑是Autoproxy的问题。以安全模式启动Firefox后,插件都被禁用,该开关选项生效了。开着,Twitter能打开;关了,Twitter打不开。

用Wireshark抓包,可以看到用AutoProxy(版本0.4b2.2011041023)的时候,不管socks_remote_dns是什么值,都看不到DNS数据包。又在用户档案的extensions/autoproxy@autoproxy.org里面查找这个选项,在chrome/content/proxy.js里面看到:
/**
 * Refresh proxy name & available proxy servers
 *
 * newProxyInfo(type, host, port, socks_remote_dns, failoverTimeout, failoverProxy)
 */
proxy.server = []; proxy.getName = [];
for each (var conf in proxy.validConfigs) {
  proxy.getName.push(conf.name);
  proxy.server.push(pS.newProxyInfo(conf.type, conf.host, conf.port, 1, 0, null));
}
可以看到AutoProxy确实把socks_remote_dns设置成了1,所以在about:config里面设置也无效了。这样做的好处是用户无需知道这个选项,也可以打开被DNS污染的网站,但是最好在文档里说明一下。

2012年3月26日星期一

Bash提示符的Bug

当用户在passwd文件中的家目录最后有"/"时,Bash的提示符中"\w"指代的家目录不能缩写为"~",而是原样显示目录。我汇报了这个bug,但是作者并没承认,更没打算修复。

如果咬文嚼字,这个还真可以不算bug。Bash的手册里这么写的:
\w    the current working directory, with $HOME abbreviated with a tilde (uses the value of the PROMPT_DIRTRIM variable) 
因为这种情况下,"current working directory"是去掉"/"的,而$HOME还是有"/"的:
user@host /export/home/pan$ echo $PWD
/export/home/pan
user@host /export/home/pan$ echo $HOME
/export/home/pan/
这俩变量不相等,所以没有缩写,即使它们在“物理上”是同一个目录。但是这个问题修复了的话,可以让这种特别情况下的提示符依旧缩写,对用户更友好。

2012年3月24日星期六

Dropbox的Case Conflict

修改了主页后,用rsync同步,看到如下的画面:
*deleting   images/rms/17am/7.JPG
*deleting   images/rms/17am/4.jpg
*deleting   images/rms/17am/3.JPG
*deleting   images/rms/17am/2.JPG
*deleting   images/rms/17am/12.JPG
*deleting   images/rms/17am/10.JPG
*deleting   images/rms/17am/1.JPG
<f+++++++++ images/rms/17am/1.jpg (Case Conflict 1)
       66998 100%    3.19MB/s    0:00:00 (xfer#9, to-check=103/1237)
<f+++++++++ images/rms/17am/10.jpg (Case Conflict 1)
       90494 100%    3.92MB/s    0:00:00 (xfer#10, to-check=101/1237)
<f+++++++++ images/rms/17am/12.jpg (Case Conflict 1)
      101524 100%    4.21MB/s    0:00:00 (xfer#11, to-check=99/1237)
<f+++++++++ images/rms/17am/2.jpg (Case Conflict 1)
       76399 100%    2.91MB/s    0:00:00 (xfer#12, to-check=97/1237)
<f+++++++++ images/rms/17am/3.jpg (Case Conflict 1)
       83717 100%    3.07MB/s    0:00:00 (xfer#13, to-check=95/1237)
<f+++++++++ images/rms/17am/4.JPG (Case Conflict 1)
       20923 100%  756.76kB/s    0:00:00 (xfer#14, to-check=93/1237)
<f+++++++++ images/rms/17am/7.jpg (Case Conflict 1)
       77626 100%    2.74MB/s    0:00:00 (xfer#15, to-check=91/1237)
这些图片没有改,怎么要传送,而且出现了Case Conflict 1的字眼。

在rsync的手册里面翻了两下没看出来原因,到这这几个图片所在网页才明白。原来我的缩略图叫1.jpg,而放在同一个目录的大图叫1.JPG,其它几个图片也是如此命名的。最近用了Dropbox,这些文件同步的时候被Dropbox改名了,两个文件扩展名大小写改成一样,其中一个的文件名后加上了(Case Conflict 1)。这应该是Dropbox为了和Windows、OSX等系统下对大小写不敏感的文件系统兼容而为。

那我只好避免这种命名方式了。