2012年11月27日星期二

Nginx的414错误

请求的URI太长了,Nginx给出了414错误。可通过这个参数调整Nginx可接受的URI长度。Nginx配置中,对该server的日志记录在单独的文件中,但出错时日志只记录在默认的日志文件中。应该是请求URI太长了,Nginx还没有处理到HTTP请求的Host头部,所以不知道是哪个虚拟主机。

2012年11月13日星期二

让echo命令不显示空格

Bash里面
echo {a..z}
会显示:
a b c d e f g h i j k l m n o p q r s t u v w x y z
怎么让它不显示空格呢?试了试IFS不管用,在Freenode上问,人说echo本来就是要显示空格的。这在help echo输出的内置帮助中没有说明,但在info echo输出的外部命令手册中有说明。可以用
printf %s {a..z}
不显示空格。如果必须用echo而不显示空格,看似可以用
echo -e '\b'{a..z}
但这只是看起来没有空格,并不是单纯的26个字母的输出。如用rev倒序上面的输出得不到正确结果:
$ echo -e '\b'{a..z} | rev
                         a
cat -e来看:
$ echo -e '\b'{a..c} | cat -e
^Ha ^Hb ^Hc$
$ echo -e '\b'{a..c} | rev | cat -e

c^H b^H a^H$
顺序的时候空格不显示,但是倒序的时候,每次退格到字母下方(除了a)再打印一个空格,所以最后就只剩下a了。

2012年11月12日星期一

查看Django Debug Toolbar

我在本地打开线上staging环境的Django网站,想用Django Debug Toolbar来查看SQL查询的情况。Django Debug Toolbar显示的默认条件settings.DEBUGTrue,并且用户IP在settings.INTERNAL_IPS里面。但是manage.py启动的服务器在日志里不显示IP地址:
 [12/Nov/2012 21:05:35] "GET /releng/ HTTP/1.1" 200 275953
我想从Staging服务器上的Django日志里面看到本地电脑访问时的IP地址,找到了这个ticket,通过修改basehttp.py可显示IP:
[12/Nov/2012 19:22:21] (119.253.xx.xx) "GET /static/css/base.css?v=bc043 HTTP/1.1" 200 9301
然后把这个IP加入INTERNAL_IPS,开启settings.DEBUG即可显示Debug Toolbar了。

其实不用这么麻烦,可以在DEBUG_TOOLBAR_CONFIG里面设置'SHOW_TOOLBAR_CALLBACK'指到对应的函数即可,见Debug Toolbar的文档。

RAR压缩包乱码的处理

别人用邮件发过来的RAR压缩包(必然是Windows下创建的,我用File Roller解压缩后文件名是乱码。应该是Windows下用的GBK编码,而Linux下用的UTF8编码的问题。用Ubuntu里的unrar-nonfree包的unrar命令解压缩没有乱码,而用free版的unrar也会有乱码,可见nonfree版才会正确处理编码。File Roller集成的必然是free的代码,所以也不能正确处理。

鉴于RAR是封闭、私有的文档格式,我就不给File Roller和unrar报告bug了,他们不能处理也很正常。

2012年11月8日星期四

安装Deb包后配置文件找不到

Debuild编译打包了带封禁模块的Nginx Deb包,需要用dpkg命令安装nginx, nginx-common和nginx-full三个包。可是装完后/etc/nginx下只有几个目录,没有配置文件。上次用同样的包在Ubuntu下安装的,一切都正常。

后来发现,是dpkg -i安装时,即使依赖包没有,显示一堆错误,也会安装上去的,但配置过程会失败。大概是中途依赖没满足,安装后nginx-common包里面的conffiles没有得到配置,所以最后/etc/nginx里面没有配置文件。以后用dpkg安装时,一定要确保安装和配置一次成功,才能避免这种陷阱。