python排列*号

2013年12月10日 11:24

输出以下内容

*
***
*****
*******
*********
***********
     *
    ***
   *****
  *******
 *********
***********   
 
借用str的format可以方便的实现,但只有python2.6以上才支持
f = '{:<11}'
print '\n'.join([f.format('*' * i) for i in range(1, 12, 2)])
f = '{:^11}'
print '\n'.join([f.format('*' * i) for i in range(1, 12, 2)])
 

Tags: 字符串
评论(0) 阅读(803)

weblogic.Admin出现No available router to desctination错误

2013年11月21日 14:32

最近写一小段代码在aix 5.3系统中获取webloigc服务的状态。

执行的命令是

java weblogic.Admin -username weblogic -password weblogic123456 GETSTATE

出现的结果是

Failed to connect to t3://127.0.0.1:7001: Destination unreachable; nested exception is: 
        java.net.ConnectException: A remote host refused an attempted connect operation.; No available router to destination

很明显,它找不到路由。

试过以下几点:

1. 可以确定weblogic已经启动了,并且运行正常。

2.ping 127.0.0.1和ping localhost均正常

3. 通过指定下面url参数,也无用

java weblogic.Admin -url t3://127.0.0.1:7001 -username weblogic -password weblogic123456 GETSTATE
java weblogic.Admin -url t3://localhost:7001 -username weblogic -password weblogic123456 GETSTATE
java weblogic.Admin -url t3://0.0.0.0:7001 -username weblogic -password weblogic123456 GETSTATE

最后在url参数中将地址设置为此机器对外的ip地址,命令才运行成功。

java weblogic.Admin -url t3://135.32.21.21:7001 -username weblogic -password weblogic123456 GETSTATEjava weblogic.Admin -url t3://135.32.21.21:7001 -username weblogic -password weblogic123456 GETSTATE

输出结果为:Current state of "AdminServer" : RUNNING

很奇怪localhost与127.0.0.1竟然无效,反而使用对外的ip才有效果。

评论(0) 阅读(2090)

用python检测文件是否正在被修改

2013年11月17日 23:07

使用lsof filename 可以查询到文件正在被谁使用。下面是python实现的检测代码。

a.py检测代码

#encoding=utf-8
import os


def isOpen(filename):
    # 执行lsof命令
    p = os.popen("lsof %s" % filename)
    # lsof找到打开的文件时有输出
    content = p.read()
    p.close()
    # 通过是否有输出,判断文件是否打开
    return bool(len(content))

if __name__ == '__main__':
    print isOpen("a.log")

b.py模拟正在修改文件

#encoding=utf-8
import time

if __name__ == '__main__':
    f = open("a.log", 'a')
    while True:
        time.sleep(5)

注意只能检测到文件被谁打开的情况。在python中就是open()了一个文件,并且还没有close()掉的情况。

以下情况是检测不到的:

vim xxx

python xxx

上面是比较简陋的一种方式,更强大的功能请见pyinotify模块

评论(1) 阅读(2067)

webpy中auto_application的cookie共享问题

2013年11月16日 09:27

在webpy中使用auto_application划分网站的url结构,会发现是个很好用的东西。

使用过程中却发现每个auto_application默认有自己单独的cookie。

范例

#encoding=utf-8
import web
appA = web.auto_application()
appB = web.auto_application()

urls = (
    '/save',   appA,
    '/get',    appB
)

class SaveName(appA.page):
    path = '/?'

    def GET(self):
        web.setcookie("name", "wyq", expires=24 * 60 * 60)
        return web.cookies().get("age")


class GetName(appB.page):
    path = '/?'

    def GET(self):
        return web.cookies().get("name")

app = web.application(urls, globals())

if __name__ == '__main__':
    web.config.debug = True
    app.run()
    #print app.request("/save").data
    #print app.request("/get").data

上面代码,生成两个auto_application appA与appB。

appA处理所有以/save开头的url请求,appB处理所有以/get开头的url请求。

appA = web.auto_application()
appB = web.auto_application()

发送http://0.0.0.0:8080/save请求,将name信息保存在cookie中。

web.setcookie("name", "wyq", expires=24 * 60 * 60)
 
发送http://0.0.0.0:8080/get请求,获取name值。
预想是返回name值,却发现结果为空。什么原因呢?
观察下面从chrome中取到的截图。
/save请求
 
注意上面的Set-Cookie,多了个path=/save/。原来在application中保存cookies时,会设置cookies的path属性。
 
cookie的path属性,用于限制cookie的访问域,只有此域下的请求才能取到此cookie信息。
换句话说只有url以/save/开头的请求才能,取到此cookie的信息。
上面appA属于/save/域下的,appB属于/get/域下的。它们属于不同的域,所以appB访问不到appA中的cookie。
 
如何解决呢?办法就是在设置cookie时添加path="/"的属性,即可解决。
web.setcookie("name", "wyq", expires=24 * 60 * 60, path="/")
 
 
 

评论(0) 阅读(1020)

将[{},{}]转为dict

2013年11月14日 21:31

经常遇到一种需求,需要把从数据库取出的数据,转为dict对象([{}, {},...]-->dict)。

rs = [{"user_id":111, "name":"abc"}, {"user_id":123, "name":"edf"}]
print dict(map(lambda r:[r["user_id"], r], rs))
>>{111: {'user_id': 111, 'name': 'abc'}, 123: {'user_id': 123, 'name': 'edf'}}

上面看起来比较啰嗦,换一种写法

print dict([r["user_id"], r] for r in rs)

更简洁的写法

{r['user_id'] : r for r in rs}

 

 

评论(2) 阅读(1093)

IBUS-WARNING **: Process Key Event failed: Timeout was reached

2013年11月14日 07:10

在gvim中ibus敲字时,偶尔会在n秒之后才显示到屏幕,反应死慢。在看控制台会看到下面的错误信息.

(gvim:77687): IBUS-WARNING **: Process Key Event failed: Timeout was reached。

暂时无法搞清具体原因,所以用重启ibus的笨办法解决。

  • 杀死ibus进程

ps -ef |grep ibus-daemon 找到进程,然后kill掉

  • ibus-daemon -d -x -r 命令启动

-d 作为后台程序运行

-x 执行ibus XIM服务

-r 替换老进程

Tags: ibus
评论(0) 阅读(1335)