和 Subversion 一样，Git 也可以为 Commit Message 设置一个默认的编辑器，命令如下：
1
| $ git config --global core.editor vim |
不过我在 Mac OS X 系统使用 Git 的过程中，偶尔会遇到如下的情况：
1
2
3
4
5
6
7
| *** Commands ***
1: status 2: update 3: revert 4: add untracked
5: patch 6: diff 7: quit 8: help
What now> q
Bye.
error: There was a problem with the editor 'vim'.
Please supply the message using either -m or -F option. |
这种情况基本上都是出现在我打错字的时候，开始以为是输入法引起的 Vim 状态异常，不过出现的次数多了才慢慢发现一个规律——如果在 Vim 中编辑文本时因为按键失误出现类似这样：E492: Not an editor command… 的错误信息时，必然无法提交。
查了一下 ProGit 的文档后了解到：如果 Git 的 Commit Hooks 检测到脚本的返回非零状态码的话（Non-Zero Code，表示有错误发生），会阻止本次提交。到这里问题就比较清晰了，显然是 Vim 非正常退出返回了 Non-Zero Code。
为了验证猜测，我作了如下操作，打开终端 Vim，随便输入几个无效指令，造成 Exxx 之类的错误，然后立刻使用 :q 退出，观察返回値，结果：
1
2
3
| verdana@phpvim:~ # vim
verdana@phpvim:~ # echo $?
1 |
果然是这样呢！
后来在 Google Group: vim_mac 这个帖子中找到了解决的办法，就是使用完整的 Vim 路径—— /usr/bin/vim :
1
| $ git config --global core.editor /usr/bin/vim |
不太清楚 Mac OS X 中 Vim 为何会有这种问题，Bram 老大亲自现身作了解释：
Vim 在遇到 Exx Error 时返回 Non-Zero code 是为了兼容 Posix，不过这种情况应该只会出现在使用 Ex Mode 时，Normal/Insert Mode 是不会这样的。
今天在 vim.org 的脚本库里面闲逛的时候，无意中看到了这个颜色主题。暗色系主题，颜色运用很鲜艳，看起来很养眼，美中不足的是 comment 颜色稍微偏暗了一些，看着不是很清楚，可以打开 molokai.vim 修改一下 hi Comment … 改成亮一点的颜色…
下载地址：
http://www.vim.org/scripts/script.php?script_id=2340
Vim 中码字，在 Insert/Normal 两种模式中频繁切换是无可避免的。那么如何快速在两种模式中切换，显然影响到我们的操作效率。
这里有三个快捷键可以选择： ESC, CTRL+C, CTRL+[
从便捷性上来看，CTRL+C 貌似是最顺手的，CTRL+[ 次之（需要两只手），ESC 最麻烦了，左手需要离开键盘的主要操作区域。
从功能上来看，ESC 等同于 CTRL+[，两者是完全一样的。CTRL+C 则稍稍不同，区别在于它不会自动展开 abbreviations，也不会触发 InsertLeave 事件。在某些些情况下，这可能会造成一点小小的困扰，比如下面的配置。
1
2
3
4
| " 当切换 Insert/Normal 模式时，动态修改状态栏颜色
hi StatusLine guifg=#FBFAFB guibg=#755939 gui=bold
autocmd InsertEnter * hi statusline guifg=#FBFAFB guibg=#44507F gui=bold
autocmd InsertLeave * hi statusline guifg=#FBFAFB guibg=#755939 gui=bold |
如果使用 CTRL+C，那么上面最后一行配置就不起作用了。
好在 Vim 可以重新定义按键：
1
2
3
4
| inoremap <C-c> <ESC>
" 或者作一些小小的改进
inoremap <C-c> <ESC>`^ |
abbr 依然不会自动展开，实际上这个不是问题，可以使用空格、回车，CTRL+]等等替代，重要的是 InsertLeave Event 回来了。
光标的漂移
默认的情况下，当你按 <ESC> 返回 Normal 模式时，光标会向左边移动一个字符，上面的第二个映射命令中添加了 `^，这样就能让光标保持原来的位置，不再乱跑了。
更多相关的知识请参考（准备好梯子） 
：
http://vim.wikia.com/wiki/Avoid_the_escape_key
找不到《空中监狱》的版本 How do i live，只好听听原版了~
Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.
PS: 看来无法引用 Google Music 的地址，隔了一天发现地址变了 
大多数人在使用 Bash 时，都会对其进行改造，因为默认的设置真的好难用～
参考以下 ~/.inputrc 设置：
1
2
3
4
5
6
7
8
9
| # do not show hidden files in the list
set match-hidden-files off
# auto complete ignoring case
set show-all-if-ambiguous on
set completion-ignore-case on
"\ep": history-search-backward
"\e[A": history-search-backward
"\e[B": history-search-forward |
默认情况下，按下两次 <tab> 才会出现提示，show-all-if-ambiguous 开启后，只需要一次了。
关掉 match-hidden-files 不显示隐藏文件，特比是当你在 Home 目录时，你会觉得眼前好干净。
开启 completion-ignore-case 忽略大小写，写 PHP 时我估计大约 1/4 的按键都是 shift + 4，该死的美元符号！Shell 命令，我不想再和大写字母纠缠了，让 <tab> 搞定好了。
history-search-*，输入几个字母，按上下箭头，搜索你的历史命令。
更多 Bash 定制请参考：
https://wiki.ubuntu.com/Spec/EnhancedBash
Git 的好处之一就是把代码的分支管理变成了一件极其便捷的事情，分支只保留差异，不用复制任何文件，不用连接网络，快速创建，用完即删。Git 分支与项目的复杂程度无关，不管你的项目多么复杂，创建 Git 分支永远都是瞬间的事情。同时，因为保留了父类分支的信息，所以分支的合并也变得异常简单。
当在一个项目中频繁使用多个分支时，可以使用 git status 命令查询自己现在正工作在哪个分支下面，不过难免有脑子发昏的时候，忘记自己在哪个分支下面，因而发生误操作之类的杯具。
那么把分支显示在 Shell 提示符中无疑方便了很多，再也不需要频繁的使用 git status 命令了…
实现原理很简单，大体就是查询当前目录下面的 Git 分支名称，然后嵌入到 PS1 变量中。那么，Git 分支名称可以通过下面的脚本轻松的获得：
git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'
把上面的脚本封装到函数中，修改 PS1 变量，嵌入函数… 大体是这样。但是这样也意味着一个问题，就是每次 shell 活动（比如切换目录，甚至只是敲下回车）都会执行一次 git … sed 命令，这样每次都启动2个进程，实在是有些不爽。
好在，可以使用另外一种方式来获取 Git 分支名称，在每个 Git 项目中，都有一个 .git 目录，这个目录下面有个叫做 HEAD 的文件，里面包含的当前分支的路径信息：
ref: refs/heads/BRANCH-NAME
我们只要读取这个文件，然后再和对应的路径互相匹配一下就知道正确地分支名称了。不要只是简单的从 HEAD 内容中拆分出最后的 BRANCH-NAME，因为它不一定是正确地。
以下是 Aaron Crane 的实现方式：
## Parses out the branch name from .git/HEAD:
find_git_branch () {
local dir=. head
until [ "$dir" -ef / ]; do
if [ -f "$dir/.git/HEAD" ]; then
head=$(< "$dir/.git/HEAD")
if [[ $head = ref:\ refs/heads/* ]]; then
git_branch=" → ${head#*/*/}"
elif [[ $head != '' ]]; then
git_branch=" → (detached)"
else
git_branch=" → (unknow)"
fi
return
fi
dir="../$dir"
done
git_branch=''
}接下来，将这个函数加入到 PROMPT_COMMAND 中，保证 Bash 在创建 prompt 之前调用这个函数取得分支名称：
PROMPT_COMMAND="find_git_branch; $PROMPT_COMMAND"
最后只要重新定义 PS1 变量即可：
# Here is bash color codes you can use
black=$'\[\e[1;30m\]'
red=$'\[\e[1;31m\]'
green=$'\[\e[1;32m\]'
yellow=$'\[\e[1;33m\]'
blue=$'\[\e[1;34m\]'
magenta=$'\[\e[1;35m\]'
cyan=$'\[\e[1;36m\]'
white=$'\[\e[1;37m\]'
normal=$'\[\e[m\]'
PS1="$white[$magenta\u$white@$green\h$white:$cyan\w$yellow\$git_branch$white]\$ $normal"以上的代码你可以放在 ~/.profile 或者 ~/.bash_profile 等文件中即可，我的系统是 Snow Leopard，PS1 定义在 /etc/bashrc 中，所以我直接修改的这个文件。
最终效果如下：
UPDATE – 2010/06/23:
如果你安装了随 Git 附送的 git-completion.sh 子命令自动完成脚本，也可以使用该脚本提供的方法：
export PS1="[\u@\h \W"'$(__git_ps1 " (%s)")'"]\$ "
Ubuntu 系统，请参考： /etc/bash_completion.d/git
参考文献：
http://www.jonmaddox.com/2008/03/13/show-your-git-branch-name-in-your-prompt/
http://aaroncrane.co.uk/2009/03/git_branch_prompt/
这两天网上开始疯传一个“nginx文件类型错误解析漏洞”，这个“漏洞”是这样的：
假设有如下的 URL：http://phpvim.net/foo.jpg，当访问 http://phpvim.net/foo.jpg/a.php 时，foo.jpg 将会被执行，如果 foo.jpg 是一个普通文件，那么 foo.jpg 的内容会被直接显示出来，但是如果把一段 php 代码保存为 foo.jpg，那么问题就来了，这段代码就会被直接执行。这对一个 Web 应用来说，所造成的后果无疑是毁灭性的。
关于这个问题，已有高手 laruence 做过详细的分析，这里再多啰嗦几句。
首先不管你是否有用到正则来解析 PATH_INFO，这个漏洞都是存在的。比如下面这个最基本的 nginx 配置：
1
2
3
4
5
6
| location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
} |
漏洞同样会出现，如 laruence 所说，实际上这个漏洞和 nginx 真的没什么关系，nginx 只是个 Proxy，它只负责根据用户的配置文件，通过 fastcgi_param 指令将参数忠实地传递给 FastCGI Server，问题在于 FastCGI Server 如何处理 nginx 提供的参数？
比如访问下面这个 URL：
1
| http://phpvim.net/foo.jpg/a.php/b.php/c.php |
那么根据上面给出的配置，nginx 传递给 FastCGI 的 SCRIPT_FILENAME 的值为：
1
| /home/verdana/public_html/unsafe/foo.jpg/a.php/b.php/c.php |
也就是 $_SERVER['ORIG_SCRIPT_FILENAME']。
当 php.ini 中 cgi.fix_pathinfo = 1 时，PHP CGI 以 / 为分隔符号从后向前依次检查如下路径：
1
2
3
4
| /home/verdana/public_html/unsafe/foo.jpg/a.php/b.php/c.php
/home/verdana/public_html/unsafe/foo.jpg/a.php/b.php
/home/verdana/public_html/unsafe/foo.jpg/a.php
/home/verdana/public_html/unsafe/foo.jpg |
直到找个某个存在的文件，如果这个文件是个非法的文件，so… 悲剧了~
PHP 会把这个文件当成 cgi 脚本执行，并赋值路径给 CGI 环境变量——SCRIPT_FILENAME，也就是 $_SERVER['SCRIPT_FILENAME'] 的值了。
在很多使用 php-fpm （<0.6） 的主机中也会出现这个问题，但新的 php-fpm 的已经关闭了 cgi.fix_pathinfo，如果你查看 phpinfo() 页面会发现这个选项已经不存在了，代码 ini_get(“cgi.fix_pathinfo”) 的返回值也是 “false”。
原因是似乎因为 APC 的一个 bug，当 cgi.fix_pathinfo 开启时，PATH_TRANSLATED 有可能是 NULL，从而引起内存异常，造成 php-fpm crash，所以 php-fpm 关闭这个选项。
前几天把工作平台从 Ubuntu 9.10 Karmic 更新到了 10.04 Lucid，由于 Lucid 官方源自带了 PHP5.3.2，以前使用的 dotdeb 的源就没法用了，一直很喜欢这个源的，不但提供了 PHP5.3 而且还有 php5-fpm 这个很实用的 fcgi 进程管理器，这个在官方源里面是没有的。强行上了 dotdeb 虽然也可以，不过必然有很多包会出现依赖问题，处理这些依赖关系是件很烦心的事情。哥啥都不怕，就怕麻烦～ 
对于 PHP 来说，php-fpm 还是最合适的，spawn-fcgi 这类东西就不用考虑了，我宁愿用 PHP5 内置的 FastCGI Server。
Read more…
搬到孵化园已经一个月了，很忙，很烦…
从去年的年底到现在，对我来说有了很大的变化，也有不少的收获。在朋友的帮助下，顺利地组建了自己的 Web 外包团队，落户在了高新孵化园。网站外包，真的是件很没技术含量的事情，也没什么油水可捞，不过倒是一条锻炼团队的途径。
自己也和哥们从东门建设路住了近10年的老房子里面搬到了外双楠，传说中非富即贵的富人区，有多少富贵人家我不知道，我只知道外面吃得东西真他娘的贵！一个人随便找个馆子一顿吃下来就几十块就没了，这也算是刺激自己努力赚钱的动力吧~想想你如果吃了N年的炒饭，面条，而现在还在吃这些的东西，那就太凄凉了！
原来住的老房子在建设路，某半死不活的国企职工宿舍，风水很不好，帮我们看房子的风水师傅说，这里叫做空亡之地。我对命理学一窍不通，不过从字面上看也知道不是什么好地方。大师还帮我们看了八字，给我解释的东西，我都忘光了，只记得关于华盖的一些话。命里有华盖的人通常都是才华横溢、性情恬淡的主，被人说自己聪明当然是件开心的事情，不过后来我发现了其实大师也有很多话没有说，那就是华盖通常也意味着不愿与人交往，常常感到孤独，而且通常与宗教有缘，好吧，我命里不但有华盖，而且还是三个，只能叹一声：马勒戈壁的！
本来还想问问姻缘的，没好意思！ 
搬家的时候，带了以前女友的照片，放在电脑桌上，为此还被哥么给嘲笑了一番。笑就笑吧，我忘不了这个女人，和她之间发生的一切，已成昨日黄花。快3年过去了，唯一留下的，就是这张照片还有那永远挥之不去的浓浓情意萦绕在心头。我一直在想，什么时候可以再见到她呢？只是见见也好，怕只怕这辈子再也看不到她了。我为爱烦恼，只因太执着，人常说，男子汉大丈夫，当拿得起放得下，我拿起了这份感情，却再难放下。
父亲常常打电话催我结婚，这样的日子持续了1年多了直到现在依然如此，有段时间几乎是以每天1，2个电话的高频率给我洗脑，灌输男大当婚、女大当嫁的观念，搞的我一听到手机响，就郁闷不堪，很想把手机从窗户扔出去。不过电话还是要接的，于是每次只能信誓旦旦的和父亲保证一定给他找个好儿媳，就这样日子一天天的过去，儿媳还是没着落，父亲也渐渐不再像以前那样紧紧逼迫，只是偶尔还是会提起，而我也懒的再提那些陈词滥调的保证了。呵呵，像我这样的没钱没车没房的头顶三华盖的孤僻三无宅男，想要找个老婆，还真是件极具挑战性的事。在天朝这个环境里，根本是不可能的嘛，哪怕天上真的会掉下个林妹妹，只怕也是脸先着地的，好吧，我宁愿孤独终老，也不愿意委屈自己，寂寞归寂寞，不过反过来想，不也是一生自由自在，不受约束，逍遥快活的么？哎，就当我阿Q好了！笑~ 
学习使用 Vim 大约已有4、5年了，直到今天仍然有很多不懂的东西，精通自然谈不上，只能说初窥门径。看 best of vim tips 的作者是怎么说的：
David Rayner (zzapper) 15 Years of Vi + 4 years of Vim and still learning
这位大叔，搞了 15 年的 Vi，又搞了 4 年的 Vim，可依旧在学习。看来 Vim 真的是一个可以学到死的文本编辑器。
奇妙的之处就在于，你并不需要完全精通 Vim才能应用到工作中。实际上你只需要了解一些基本的东西，比如模式，光标移动，几个基本的编辑命令就可以让你的编辑效率提高很多，其它的就在实际的工作中根据自己的需要慢慢发掘。
如果你初次接触 Vim，那么建议你运行一下 Vim 安装目录下下面的 vimtutor，了解一下 Vim 的基础知识，花几天时间你就能完全适应它；如果你已经被 manual 中各种眼花缭乱的指令吓傻了，建议你忘掉那些指令，就算暂时记住了，如果用不到你也很快会忘记。
下面是我在网上看到的一个牛人写的教程，涉及到了 Vim 中的很多高级特性，但没有太多让人眼花的指令，读完之后定会有所收获。
