标签 Python 下的文章

Python脚本命令行变量的实现

我们知道Make工具是支持命令行变量的,这种手段为我们提供了很好的灵活性,我们可以通过敲入不同的命令行参数来决定Makefile脚本的行为。

make [variable1=value1 variable2=value2 ... ... ]。

#
# Makefile
#

CMODE = 64-bit

ifeq ($(CMODE), 64-bit)
    CFLAGS += -m64
endif
  
all:
    gcc $(CFLAGS) -o foo foo.c

$> make
gcc -m64 -o foo foo.c

$> make CMODE=32-bit
gcc -o foo foo.c

近期我们的一个Python脚本工具也有类似的需求了,但Python脚本原生并不支持这种命令行变量,我们来看看是否可以利用Python提供的机制实现一种可以满足我们需求的命令行变量。

我们的期望结果如下:

$> foo.py fruit=apple

# foo.py

flag = '' #这个定义可以有,也可以没有,如果有,可以理解为默认值

….

if flag == 'apple':
    ….
elif flag == 'orange':
    ….
elif flag == 'banana':
    ….
else:
    ….

Python是动态语言,提供了注入eval、exec等在运行时执行代码的能力。我们要实现命令行变量的机制,离不开这些能力的支持。eval用于求值表达式,而x=y是语句,我们只能用exec。

【#1】

import sys

if __name__ == '__main__':
    c = len(sys.argv)
    if c <= 1:
        print "found zero command variable"
        exit(0)

    exec(sys.argv[1])

    if fruit == 'apple':
        print 'this is apple'
    elif fruit == 'oracle':
        print 'this is orange'
    elif fruit == 'banana':
        print 'this is banana'
    else:
        print 'other fruit'

$> foo.py fruit=apple

Traceback (most recent call last):
  File "./foo.py", line 18, in <module>
    exec(sys.argv[1])
  File "<string>", line 1, in <module>
NameError: name 'apple' is not defined

上面的例子执行后,提示'apple'没有定义。执行foo.py fruit="apple"得到的也是同样的错误。从内部输出来看,无论是fruit=apple还是fruit="apple",exec的参数始终都 是fruit=apple,导致exec抱怨apple这个符号没有定义。

我们打开一个Python命令行交互窗口,做如下测试:

$> python
Python 2.7.3 (default, Aug  1 2012, 05:14:39)
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> exec("fruit=apple")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
NameError: name 'apple' is not defined
>>> exec("fruit='apple'")
>>> fruit
'apple'
>>> exec("num=1")
>>> num
1

通过这个小实验可以看出,我们不能将命令行参数直接原封不动的传给exec,我们要对其进行一下加工,加工的效果如下:

fruit=apple => fruit='apple'
num=1 => num=1

【2】

import sys

def __convert(source):
    (var, sep, val) = source.partition("=")
    if val.isdigit():
        return source
    return  var + "=" + "\'" + val + "\'"

if __name__ == '__main__':
    c = len(sys.argv)
    if c <= 1:
        print "found zero command variable"
        exit(0)

    exec( __convert(sys.argv[1]))

    if fruit == 'apple':
        print 'this is apple'
    elif fruit == 'orange':
        print 'this is orange'
    elif fruit == 'banana':
        print 'this is banana'
    else:
        print 'other fruit'

__convert函数对命令行的参数做了转换,对于数值类的var直接原封不动的返回,否则对于值为字符串的var,将其val用''包裹起来后返回。我们来测试一下新程序:

$> foo.py fruit=apple
this is apple
$> foo.py fruit=orange
this is orange
$> foo.py fruit=watermelon
other fruit

从输出结果来看,我们的预期是达到了^_^。上面的程序只是示例性质的,Python的exec具有运行时执行动态代码的能力,我们在获得这种强大能力的 同时,也面临着巨大的风险。一旦恶意代码从外部传入被exec执行,将带来严重的后果。因此对于exec要执行的代码务必要预先进行必要的形式校验。

buildc 0.3.0版本发布

buildc正式在项目中应用以来,我们收到了许多同事针对buildc演进的意见和建议。其中确实有些易用性的问题是在最初设计时未考虑周全的,尤其是.buildc.rc中的配置,同事们对该文件的配置已经“怨声载道”了。

.buildc.rc是用来配置某开发者在开发过程中使用的第三方库所在subversion repository信息的,例如:

a_repository = ('SVN库地址', '本地缓存路径',
              [
                  # 格式:[(“第三方库名称”, “库版本”, “特征库文件”), …]
                  ('libevent', '2.0.10', 'lib/libevent.a'),
                  ('instantclient', '10.2.0.5.0', 'lib/libnnz10.so'),
                  …
              ]
            )
b_repository = ('SVN库地址', '本地缓存路径', [])
c_repository = ('SVN库地址', '本地缓存路径', [])

external_repositories = [
                        a_repository,
                        b_repository,
                        c_repository,
                        …
                   ]

这里面需要维护最多、最频繁的就是各个repository中具备的第三方库名、版本号。开发者所开发的项目所依赖的第三方库信息发生变化,不仅仅需要修 改project下的buildc.cfg文件,还可能要修改.buildc.rc,大家维护起来确实体验不好,会多耗费一些工作量。

针对这个主要问题,我们决定对buildc进行一次较大范围的重构,重构后的版本定为buildc 0.3.0版本。以下是buildc 0.3.0版本的主要改动点:

一、简化.buildc.rc的配置,重新定义cache相关命令的语义

0.3.0及以后版本的.buildc.rc只需配置repository的地址信息以及cache缓存的本地路径信息,无需再提供repository 里面具体的第三方库以及版本号信息了,这样一来,大多数情况下,project依赖的第三方库发生变更,都无需修改.buildc.rc了。

a_repository = ('SVN库地址', '本地缓存路径')
b_repository = ('SVN库地址', '本地缓存路径')
c_repository = ('SVN库地址', '本地缓存路径')

external_repositories = [
                        a_repository,
                        b_repository,
                        c_repository,
                        …
                   ]

随之而变的是buildc cache相关命令的语义,0.3.0中cache相关命令的语义如下:

* buildc cache init - 生成.buildc.repository,该文件是svn库的目录结构文件,相当于一份svn repository内部的地图,repository中存放的各种第三方库以及版本均在该文件中索引;如果该文件已经存在,命令执行的结果为:提示已存在。

* buildc cache upgrade – 根据.buildc.rc的最新更新,重新生成.buildc.repository文件,并将该文件中所有lib本地的 Revision号置为none。该文件并不会执行本地cache的library的真实更新操作。

* buildc cache update  - 
    1. 如果.buildc.rc已经修改,但没有执行buildc cache upgrade,update会对比本地缓存库信息与对应的.repository文件中的同名lib信息,如果不一致,则提醒执行upgrade。
    2. 如果.buildc.repository是新生成的,所有lib本地的Revision号均是none,则提示没有要更新的本地缓存库;
    3. 如果某个项目已经download了自己依赖的库,那update将比对svn库中和本地库的revision差异,并下载最新库版本。并修改.buildc.repository中对应库的本地revision number。

* buildc cache remove – 将.buildc.repository中对应库的本地revision number都置为none,并删除本地缓存的库文件。

二、重新定义config make的语义

前面提到了,在执行buildc cache init时,buildc只是负责生成.repository文件,而并不真实执行库文件的下载和缓存。那何时真正下载呢?答案是在执行buildc config make时。这里颇有些“lazy evaluate”的味道,需要时再“download and cache it"。

* buildc config make

1. 如果.buildc.rc已经修改,但没有执行buildc cache upgrade,config make会对比本地缓存库信息与对应的.repository文件中的同名lib信息,如果不一致,则提醒执行upgrade。
2. 如果.buildc.rc是新生成的,或执行cache upgrade后的,config make会根据project对应的buildc.cfg中配置的第三方库,在.buildc.repository中查找是否存在(包括对应的版本 号),如果存在,则从subversion server端自动下载;否则提示出错。
3. 如果本地缓存中某个库文件不存在,buildc config make会检测到,并自动下载该库,并cache起来。
4. 如果subversion端某个库的svn revision号发生的更新,buildc config make会检测到,并下载最新的版本。

总之一切都是在buildc config make时来完成的,按需下载或更新,这样你甚至无需进行手工的library Cache维护。

三、转向OO范型

实现buildc 0.3.0的小同事(wtz1989227@gmail.com)对OO情有独钟,因此在这个版本中,他将以前的结构化代码做了大幅度调整,并用OO的方 式进行了重构。按照wtz的思路,这次改造比较初级,OOD做得还不够充分,以后慢慢调整。实际代码中反映出来的情况也的确是这样。

四、buildc 0.2.3发布

在将buildc 0.3.0代码merge到trunk之前,我创建了buildc-0.2的maintain branch,虽然理论上buildc 0.3.0在功能和配置方面与buildc 0.2.x版本是兼容的,但毕竟代码调整幅度较大。另外建议大家都转移到0.3.0这个最新版本上来,buildc-0.2分支顶多做一些bugfix, 不会再有新feature添加进去了。

昨天在发布buildc 0.3.0的同时,还发布了buildc-0.2的一个Bugfix版 – buildc 0.2.3,该版本主要做了如下一些fix:

  * 执行cache upgrade时增加对.buildc.rc中repository特征文件存在性的检查;
  * 执行config make时增加对Make.rules文件是否为空的判断;
  * 执行pack source时,添加VERSION文件,记录打包的上下文信息。

五、其它

考虑到github的活跃度远远高于google code,加上google code最近访问十分不稳定,因此之前就将buildc(还有cbehavelcut以及我的实验代码库)fork了一份到github上了,也攒攒 github上人气,因此这次buildc 0.2.3和buildc 0.3.0的代码还要发布到github上一次。git工具平时用的少,尤其是提交代码到github,这次算入门了。

* 代码远程提交
用git remote add一个github的remote repository后,就可以使用git push origin master将本地的commit推送到github上了。

* 打tag,并推送tag

   — 查看Tag的git命令是git tag
   — 本地打tag,用这个命令: git tag -a v0.2.3 -m"0.2.3 released"
   — 推送Tag到remote repository:git push –tags origin master,不加–tags是无法推送tag的。

* branch操作
  — 查看branch:git branch
  — 创建branch:git branch buildc-0.2
  — 推送branch:git push origin buildc-0.2
  — 本地切换branch:git checkout buildc-0.2

Hello,Sublime Text 2

用惯了Vim后,也会有一种尝试新Editor的冲动,这回Sublime Text 2满足了我的这个需求。据说Sublime Text是目前最火的代码编辑器之一,我周围为数不多的几个比较Geek的同事都已经开始使用Sublime Text 2或用了很长时间了,其官方网站首页的Feature Demo也的确非常地炫。

安装Sublime Text 2

我的实验环境Ubuntu 12.04.1 32-bit Desktop版,默认Ubuntu Unity桌面,iBus拼音输入法。

Sublime Text 2的安装极其简单,遵循着download(http://www.sublimetext.com/2) -> unzip -> add path -> start and use的经典路线。我下载的Sublime Text 2是2.0.1版本,启动后一切正常。

安装后目录结构

安装后的Sublime Text 2的目录结构非常简洁:

$ ls
Icon/  PackageSetup.py   Pristine Packages/
lib/   sublime_plugin.py   sublime_text*

lib下是自带的Python26环境;Pristine Packages下是各种编程语言的插件包。

在我的环境下Sublime Text 2的用户配置与包环境放在了~/.config/sublime-text-2/下面,

$ ls
Installed Packages/  Packages/  Pristine Packages/  Settings/

这里面最重要的目录就是Packages目录了,这里是Sublime Text 2用第三方包扩展自身Feature的包存储路径。

安装package control

package control包之于Sublime Text 2就好比apt工具之于Ubuntu,它是一个方便第三方包安装、卸载和管理的第三方包。在其官网(http://wbond.net/sublime_packages/package_control)上明示了其安装方法:

* 敲入 ctrl + ` 调出命令行窗口
* 在命令行窗口中输入下面的代码,回车执行。

import urllib2,os; pf='Package Control.sublime-package'; ipp=sublime.installed_packages_path(); os.        makedirs(ipp) if not os.path.exists(ipp) else None; urllib2.install_opener(urllib2.build_opener(urllib2.   ProxyHandler())); open(os.path.join(ipp,pf),'wb').write(urllib2.urlopen('http://sublime.wbond.net/'+pf.replace(' ','%20')).read()); print('Please restart Sublime Text to finish installation')

* 重启Sublime Text 2。

注意:如果需要代理访问外网的话,需要正确设置http_proxy环境变量。

敲入"ctrl + shift + p"可打开命令窗口,输入"Package Control",你会看到窗口下拉提示中Package Control支持的功能,常用的我们会选择:“Package Control: Install Package”。

安装中文支持

中国程序员每每在尝试一种国外程序员新开发的编辑器时,都会遇到中文字符集编码的问题,这次Sublime Text 2也不例外,它原生就不支持中文显示。还好中国程序员是无比聪明的,开发了ConvertToUTF8这样的第三方包,让我们可以看到中文并用中文编辑。

最简单的安装ConvertToUTF8的方法就是用Package Control安装,选择Package Control: Install Package后,搜素ConvertToUTF8,找到后,点击即可安装。安装后,你会在~/.config/sublime-text-2/Packages下面看到ConvertToUTF8包目录。

再次启动Sublime Text 2后,打开一个GBK编码的中文文档,居然提示ConvertToUTF8工作不正常。后发现ConvertToUTF8主页上有提示,Python 2.6下的ConvertToUTF8需要一个Codecs26的Package才能正常运行。下载Codecs26后,解压安装到Packages下面,重新启动Sublime Text 2,Sublime Text 2直接dump core。从Packages目录下将Codecs26删除后,Sublime Text 2恢复正常。

又细致读了ConvertToUTF8作者的README文件,发现master branch上的Codecs26是for 64位版本的,我需要下载x32 branch上的包。的确,下载并安装x32 branch上的Codecs26后,Sublime Text 2启动OK,转换中文OK了。

注意:不要与其他支持GBK转换的包(比如GBK Encoding Support)混用,否则ConvertToUTF8无法works。

解决中文输入问题

好不容易能看GBK编码的中文文件了,却发现无法输入中文,无论如何切换输入法和重启输入法,都无法输入中文。网上介绍可通过"Input Helper Package(cd .config/sublime-text-2/Packages; git clone http://github.com/xgenvn/InputHelper.git)"解决问题。问题的确可以解决,不过输入中文时太麻烦了:需要先敲入"ctrl+shift+z"调出中文输入框,再在这个框里输入中文。

网上都说这是iBus输入法与Sublime Text 2的兼容问题,要想解决就要换fcitx。以前用过fcitx感觉默认输入法比较弱,不过现在fcitx有google pinyin了,体验一定会提高不少。通过下面命令一键安装fcitx:

sudo apt-get install fcitx fcitx-googlepinyin

安装后,在“语言支持”中用fcitx替换掉iBus。在“启动应用程序”中加入:

名称: Fcitx
命令: /usr/bin/fcitx -d
注释t: Fcitx启动

注销再登录后,再打开Sublime Text 2,终于可以输入中文了。

功能

用了一遭儿,Sublime Text 2最吸引我的Feature包括:“Goto Anything”和“Multi-Selection”。在一个工程中,通过ctrl + p调出一个输入框,Sublime Text 2首先在文件名级别对你输入的文本进行匹配;待选择好文件后,继续输入@,可看到下拉列表中显示这个文件中所有函数名的名称列表;如果输入的是#,那么下拉列表中将显示该文件中的所有符号。选择某个函数名或符号后,光标将停留在某个符号上,这时我们可以用Multi-Selection这个功能了,如果你要将这个文件中同名符号全选出来,直接Alt+F3即可;如果要选择接下来的N个同名符号,那么敲入N次ctrl + D即可。

不过要想实现ctags那种在符号上跳转到符号定义或符号调用者的功能,Sublime Text 2还无法原生支持,可考虑安装Sublime Text 2的Ctags插件实现:直接在Packages目录下git clone https://github.com/SublimeText/CTags.git。之后:
- “ctrl +t, ctrl+ r"会重新生成tags文件(前提:系统内安装了ctags程序)
- "ctrl +t, ctrl + t"会跳到光标所在符号的定义处;
- "ctrl + t, ctrl + b"会跳回上次的位置;

感受

Sublime Text 2给我的最大感受就是“快”!你在搜索、切换符号、选择文件列表中文件或符号的同时,整个文件会同步的展现你的屏幕上。




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:


如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:


以太币:


如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多