开始使用git。对着在线文档读了几天，一边还试着用。今天要提交一份有.svn文件的工程到git里面，想把.svn给无视掉。我是用命令行方式操作的，一开始很自然地想到 是否可以在 git add XXX 后面跟个什么选项什么的把.svn给exclude掉，或者是否可以用正则 ，比如 src/*!(.svn/*) 这样的。结果发现正则是不行的，不论我用哪种shell的正则方式。查了下 git add的命令手册，也没发现有exclude的选项……于是接着搜索，看到相关讨论还不少，stackoverflow上面的确有点不错的料。仔细看了会大致上了解了，得到.git/info/exclude里面去写，或者在.gitignore里面写，或者在core.excludefile里面写。 那么写就写吧，于是切进exclude文件，直接加进了“*/.svn/*”，然后先git rm -r --cached src/ 然后git add src/， 然后git status

。。。

居然不行！.svn目录居然还存在！！难道是匹配错了？我又改成正则的方式，试验还是不成！再改别的一些匹配方式，都不成！！

这让我很郁闷，只能接着搜答案，读文档。

在仔细地读了一遍gitignore的manpage之后，总算搞清楚了。它的匹配方式根本就是wildcard，并且*不表示“/”，也就是说.svn/*只能囊括.svn下的一级文件，子文件夹根本无能为力。同样的*/.svn也有毛病。正确的匹配方式应当是直截了当干干净净的

.svn/

今天有個需求，要在存儲過程中取出當天的一些配置進行比較。但是這個配置是每天輸入的，那麼當尚未輸入的時候，這個比較會報出“NO_DATA_FOUND”的錯誤。解決辦法當然也有，在之前做個判斷或者在之後的exception裡進行一些操作都可以。但是兩者都會有更多的語句要寫，讓我很煩躁。我於是想用NVL來實現。

select nvl(replyexpected,'1') from USR_DFW_SCHE where SendDay=trunc(sysdate)

今天的配置已經輸入了，自然這條語句可以正確取出值。為了測試尚未輸入記錄的情況，我將sysdate改成了sysdate+1,也就是：

select nvl(replyexpected,'1') from USR_DFW_SCHE where SendDay=trunc(sysdate+1)

結果返回的不是我預想中的'1'，而是什麼也沒有。

採用Decode()函數也一樣：

select decode(replyexpectd,NULL,'1',replyexpected) from USR_DFW_SCHE where SendDay=trunc(sysdate+1)

結果無任何返回。

將語句分解，在當天記錄存在的情況下，select '1' from USR_DFW_SCHE where SendDay=trunc(sysdate) 返回 ‘1’，而 select '1' from USR_DFW_SCHE where SendDay=trunc(sysdate+1） 這樣連滿足條件的記錄都沒有的查詢，則不返回任何結果。

由此，我想大致可以推斷Oracle的NVL()和Decode()函數的內部實現應該是這樣的過程：

 select A  from TB_C where cond=D;

 if (A is null) then

    select B into result from TB_C where cond=D;

   return B;

end if;

前几天跟金华方面做一个WebService接口,对方是.NET的,我是Java的,用cxf从wsdl中生成代码,然后直接调用.非常顺利.

因为开始的是个测试用的接口,于是昨天那边换了个正式的地址,据对方本人说,他只是把一模一样的程序换了个地方部署罢了.然而我拿到wsdl然后生成了新的接口Java文件后,就死活不成了,一直报错:服务器未能识别HTTP标头SOAPAction的值:XXXXXX

在网上查了下,大多说这是Java作为客户端连接.NET的服务端时出的问题,然后给出了两种方法.一种是.NET上加一个一句话,一个是Java这边加一起.我折腾了很久,两边都加上试了试,发现均不起作用.

今天接着搞这个问题.在修改了多次代码后,出的错误终于开始显现出区别.最后,在一条报错日志中我找到了我设定的CXF在Spring中的配置文件.打开一看,恍然大悟.

昨天有人跟我说可以用正则表示汉字,当然,是限于Unicode编码的,准确地说,是UCS2编码的汉字.然后给出了正则式:/[\u4e00-\u9fa5],或者[\x00-\xff]+  

我读过《正则表达式》那本书,知道不同的程序对于正则的实现方式会略有区别,于是就问了,这是哪里的正则.同时,打开了我的VIM开始尝试.那边回答说这是Ultra Editor的.果然,VIM中两者都无法工作.

今天又琢磨了一阵,将第二个改为[\x00-\xff],去掉了最后的+号,在VIM中输入:%s/[\x00-\xff]/1/g,结果有效,成功地替换了汉字成1。但是却又发现一个神奇的现象:有个字始终替换不了,那个字就是"犯",UCS2编码72af.

而[\u4e00-\u9fa5]则一直没能成功.我想到原生的UE里面试试,但是不知道UE的正则如何启用.在查找里面打开了正则表达式的开关,然后输入这个式子,那是毫无作用,仅仅等于[4e009fa5].

===================== 以上写于2010-10-21=======================

今天又翻出这篇来，是因为最近做了次正则的汉字匹配，突然发现以前好像写错了。我必须用[^\x00-\xff]才能匹配到汉字，跟原来的正好相反！！

难道是当初笔误了吗？当时有两个人一起试验的啊，按理说没理由都看错的啊……

2011.7.15

用vim习惯于显示行号,用less也想要显示行号.没行号找东西太麻烦了.开始连能不能显示行号都不知道.看了man手册,发现可以用 -N ,只是在打开大文件的时候会略微拖慢点速度. 拖慢点就拖慢点了,无所谓. 于是设置了 "alias less=less -N". 然后又发现一个问题.这行号显示得也太别扭了.前面空了老大一块空白,后面跟个行号,然后一个空格之后就是正文了,很容易搞混.我于是想把行号分开点,如果能彩色那更好了.

查遍了man,除了看到个没效果的 -R 之外,没看到什么关于颜色的东西. 上网查了下, -R 是用来支持解析ANSI颜色代码的,而不是less自己能用颜色.至于对齐之类的,我都不知道怎么查......

于是就想着反正开源嘛,改源码吧. 从GNU上下载了最新的less,2008年产的418版.机器上原来用的是394版,略微升级了.解压后,看到好大一堆文件.然后开始找.都不知道关于打印行号的这段在哪个文件的哪个部分.在Linuxsir上也发帖问了,不过还没人给出答案. 好在看了数个文件后,机缘巧合之下,让我翻到了 line.c 这个文件.没翻几行,就找到了关键的地方.它的关键部分是这样写的:

if (linenums == OPT_ONPLUS)
        {    
                char buf[INT_STRLEN_BOUND(pos) + 2];
                int n;

                linenumtoa(linenum, buf);
                n = strlen(buf);
                if (n < MIN_LINENUM_WIDTH)
                        n = MIN_LINENUM_WIDTH;
                sprintf(linebuf+curr, "%*s ",n, buf);
                n++;  /* One space after the line number. */
                for (i = 0; i < n; i++) 
                        attr[curr+i] = AT_NORMAL;
                curr += n;
                column += n;
                lmargin += n;
        }  

要点在"sprintf(linebuf+curr, "%*s ",n, buf);"这一句.这句打印出了行号,并给不足最小长度MIN_LINENUM_WIDTH的地方填上了空白.如果我要单纯地去除这些空白,只需要把前面的"n = MIN_LINENUM_WIDTH" 这一整个条件判断去掉,然后改成"sprintf(linebuf+curr, "%s " buf);". 只是这样一来,在行号从一位变成两位,从两位变成三位等类似的时候,正文整体都会偏移一个字符,看上去很不美观.所以还是需要保留那些空白,最多把MIN_LINENUM_WIDTH改小一点.然而靠右对齐实在不可忍耐.所以我最后改成了"sprintf(linebuf+curr, "%-*s ",n, buf);" 在前面加一个"-",使之左对齐.

这样修改后,对齐问题算是解决了.就是颜色依然没法搞定.

 最近想完成一个脚本,实现不通过数据库而直接把号码按地区分类的功能.脚本用bash写的,内容如下:

#!/bin/bash
LIST=`grep $1 head|awk '{print $2}'`
for i in $LIST;
do 
grep $i $2 
done

 但是,"grep $1 $2"确始终不能正常执行.我打印出$LIST,一切正常,打印出$i,也一切正常.

后来有人提示,DOS格式的文本会以'\n\r"结尾,而我的awk并不能识别这一点,会把末尾一并截取,使得grep时错误.改成

awk -v RS='(\n|\r)+' '{print $2}'

即可.

我的文本文件的确是从windows传过去的,于是修改后试验了下.果然问题解决了.

最终脚本如下:

#!/bin/bash
LIST=`grep $1 head|awk -v RS='(\n|\r)+' '{print $2}'`
for i in $LIST;
do 
grep $i $2 
done

今天WOW的台湾服务器也随着上周美服的脚步，更新到3.3.5了。翻看了下patchnote，在UI方面一个主要改动是好友列表那里跟战网进行了组合，当然这个改动对台湾服务器而言是没有作用的。全世界都用战网ID登录，甚至依然停留在TBC阶段的CWOW都用的战网ID，台湾服务器依然固守原样。

实质作用虽然没有，但是晚上还没上线更新剑杰就在QQ上跟我说好友列表不能显示中文了。我第一判断是：字体文件。美服客户端自带的字体文件都不包含中文字符。之前都使用在安装目录下另建Fonts文件夹，然后放入同名文件的方法，先于MPQ包中的字体文件被系统调用，达到显示中文的目的。然而系统中对字体文件的调用并不是铁板一块所有地方都一致的，而是根据各个Frame的不同，各个出现位置的不同，调用了多个不同的字体文件，并且各有scale大小之分。这种不同调用的具体规则定义在MPQ包的一个XML文件中。

 前段时间准备把录音文件改名，很自然地，用到了File类里的renameTo方法。这个方法的用法遍地都是，无外乎如是：

File oldf=new File(oldpath);
File newf=new File(newpath);

if(oldf.exists){

 if(oldf.renameTo(newf)){
    
    Log.println("修改成功");

  }else{

    Log.println("修改失败");

  }
}

但是，运行之后，发现全部都是修改失败。 上网找了下原因，有人列出renameTo失败的三种情况：

1.源文件不存在

2.目标文件存在

3.文件系统不对

当然，还有人补充了别的一些原因，比如没有修改权限等等。然而，这些对我的情况来说，都不成立。首先我是windows系统的administrator，不存在权限不足的问题；其次，我是在同一个分区的同一个文件夹里改名，也不存在磁盘分区问题；再次，源文件存在而目标文件不存在。这些可能的原因一个都不是，那到底问题出在哪呢？

这个折腾了我很久。直到有一天我想手动改名实验下的时候，发现症结所在了。我的newpath，也就是要改的名字，里面带了“*”号！！ 我原本是想用这个作为分隔符的，没想到这个恰好是windows禁用的符号……早知道如此，我直接用“#”号不就完了！！