Archives for A Wing by Wind

emacs + cygwin again

两年前我写了一篇博emacs + cygwin fail,说的是在cygwin中使用emacs的种种不便。这些问题已经得到解决。但如今我的需求又有了转变,想在native emacs on windows上使用cygwin作为shell,于是又产生了新的问题。今天看到ownwaterloo在我博客里的留言,想到应该花点时间把以前遗留下来的问题解决掉,于是有了这篇文章。

在emacs中使用cygwin作为shell,可以使用这个cygwin-shell.el
http://lists.gnu.org/archive/html/help-gnu-emacs/2010-02/msg00668.html

然后在.emacs中如此启用之


(load "D:\\programs\\emacs-24.3\\site-lisp\\cygwin-shell.el")

为了方便可以绑定一个快捷键


(global-set-key (kbd "M-s") 'cygwin-shell)

cygwin_break_emacs

重启emacs试用,发现不工作,原来是bash的路径需要填对:


(let* ((shell-file-name "D:\\cygwin\\bin\\bash")

再进去看,可以用了,但是提示符乱码。根据网上的一些讨论,打开bash.bashrc查看


# Set a default prompt of: user@host and current_directory
PS1='\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ '

由于我用的emacs版本支持分色显示,我删除了前面的\w\a部分,保留了分色显示的\u@\h部分。


# Set a default prompt of: user@host and current_directory
if [[ $TERM = "emacs" ]]; then
    PS1='\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ '
else    
    PS1='\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ '
fi

还有一个问题,就是登录进去后显示两行错误:

bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell

这是说emacs没有提供TTY给bash,因此bash拒绝提供job control功能,也就是说C-c强关进程、&后台执行、C-z挂起等命令行功能都不能使用,非常不便。其实我一般不太用到这些功能,偶尔用到就用emacs的多窗口开多个窗口来执行不同的命令,很长时间就没有去管他。今天由于跟ownwaterloo邮件提到,就想试试解决一下。根据网上的说法,这是个没有解的BUG。。

不过这个问题是从cygwin 1.7.10之后才出现的,可以找到许多帖子在升级到1.7.10~1.7.11过程中抱怨这个事情

既然如此,就不去费心琢磨怎样能给cygwin一个TTY环境了。只好根据人家提供的两条解决方案想想看怎样去找到旧版本的cygwin。

Workarounds:

* Use Cygwin Emacs (package emacs-w32 uses the windows GUI, there are also X11 and console packages)
* Don’t upgrade Cygwin above, I think Cygwin1.dll, version 1.7.9.

由于cygwin官网并不提供旧版本的cygwin安装,只好去找旧版本的镜像。我尝试了许多关键词,搜了一下午,踏遍无数国外的垃圾下载站,被各种坑骗之后,终于在一个必须注册才能下载的网站找到了可以安装的1.7.9版本,号称最后一个兼容emacs的cygwin版本的下载
http://search.4shared.com/postDownload/lMzinjJj/cygwin_179-1.html
emacs-cygwin

直接将1.7.9的cygwin1.dll拷贝到bin目录是不可行的,我下载并尝试过,bash可以执行,但是一些命令,如ls和svn执行没有输出。奇怪的是其他的程序如grep和git又可以执行,可能只是几个函数的挂接点有变化了吧。因此必须重新安装一遍cygwin。方法是启动旧版本的setup.exe后,选择“Install from Local Directory”,并在后续步骤中的“Local Package Directory”选择下载文件附带的那个路径“Cygwin_Arquivos”(我查了一下这似乎是葡萄牙语的Archive的意思,感谢这位葡语程序员!)
cygwin_arquivos

完成安装后,一种方案是可以将cygwin-shell.el中的bash路径指向新装好的cygwin路径,我没有采用。由于我已经在原有的cygwin 1.7.20版本中安装了不少应用,不想切换目录了,因此我尝试将1.7.9的bin目录覆盖到1.7.20中去。居然成功了![其实失败了…]

这次在emacs中测试,正确启动,一切命令正常!有趣的是,用cygcheck -c cygwin检测,查出来的版本还是1.7.20版本。而且新版的mintty.exe也可以正确的使用。非常开心~这暂时可以算是完美解决了~

假如有其他人恰好有跟我一样的蛋疼需求,想在windows native emacs中启用cygwin,又不堪各种坑查到我的博客,为了方便这样的小众同好,我这里给一个百度网盘的link吧。说实话百度开放网盘内容搜索还算挺有用的(虽然总感觉挺可怕的。。),我曾幻想在google中 site:pan.baidu.com 搜索cygwin 1.7.9就能搜到程序包,可惜失败了。这次我提供公开下载,未来再这样搜索的人就能得到方便了吧!

[cygwin 1.7.9 本地安装包] http://pan.baidu.com/share/link?shareid=661677505&uk=3423312229

后注

  • 事实上直接将1.7.9 bin目录中的内容覆盖到1.7.20中是不行的,部分程序无法执行。还是需要老老实实将脚本中的bash路径指向1.7.9版本。
  • 现在在Google中搜索cygwin 1.7.9 inurl:pan.baidu.com会直接找到这个资源了,只有一个搜索结果,就是我的链接,哈哈

google cygwin 1.7.9

本文引用的图片和部分讨论来自网上,以下是主要参考来源的整理

本文参考

恭喜银桑成功升级为银他妈~~

前两天银桑闹腾得特别厉害,到周二晚上周三凌晨,那一宿就没让我睡,拼命想叼着我的手拉我到他躲着的墙角里去。。
一开始搞不明白什么意思,到了凌晨三四点钟终于悟了,估计是快要生了(对了,之前没搞清银桑的性别就给他起名字了,实际人家是姐姐。。才不是大叔呢)

IMAG0290

刚出生的小猫湿淋淋的,银他妈在帮他们舔毛

正好最近买了笼子要带他搬家,就奉献了自己的枕巾跟毛巾被,把笼子里面垫好外面包好,给他一个谁也看不见的封闭空间。一弄好都不用我招呼他自己就钻进去了,也不像之前一样哀嚎折腾我了。我也是一宿没睡就死猪一样瘫床上睡过去了。没想到到了早晨八点钟被闹钟闹醒一看,银桑已经生完了!直接升级为银他妈!想想猫咪也真是厉害,都是自己给自己助产的。淌了一阳台的血(羊水?)。。我趴下去往里一瞧,四只小家伙都挤在银他妈怀里吃奶呢,还不会喵叫,发出像家禽一样细声细气的叫声,萌萌的。

小猫出生没两天毛就长全了,四只都是白猫啊!

小猫出生没两天毛就长全了,四只都是白猫啊!

当了妈的银桑比以前老实多了,不再到处乱跑,这两天也不在夜间折腾我了。对啊人家要照顾孩子啊。好几次跑到我身边像往常一样撒娇,还没蹭两下就赶紧跑回去招呼孩子们了。

嘿嘿,不知为啥,看着这样的一家子有一种安心的感觉。莫名的“幸福”感吧。希望能把这一家子养活~等小猫三个月大了可以送人~~

学着自己长大

昨日5+跟我提到,我博客links里面许多大学同学的博客链接都坏链了,
要么就是已经年久失修,要么就是博客主题也早已大不相同,
我一看5+你小子自己的live space域名也坏了啊。
今天一边敲着代码一边听歌恰好播到了《爱的代价》这一首,喟然叹息。
那时候,我们都还在学校,大家所思所想都还那么简单、那么相同。
而如今初涉世,已是如此沧海桑田。
曾经相同的我们,已经走上了各自的路,
有了各自的幸福、各自的追求,也有了各自的烦恼。

还记得年少时的梦吗
像朵永远不调零的花
陪我经过那风吹雨打
看世事无常
看沧桑变化

那些为爱所付出的代价
是永远都难忘的啊
所有真心的痴心的话
永在我心中虽然已没有他

走吧 走吧 人总要学着自己长大
走吧 走吧 人生难免经历苦痛挣扎
走吧 走吧 为自己的心找一个家
也曾伤心流泪
也曾黯然心碎
这是爱的代价

承认错误—三门问题强力纠错

中午跟基友讨论的三门问题,我一直坚持“1/2”观点还写了很长的博客去分析。
掷骰子的上帝-冷眼看三门问题
到了傍晚,终于被基友说通了,恍然大悟自己的错误。。立刻补博客谢罪。。

基友是个不擅言辞的人,言语上一直没有说出能说服我的道理。但是他的一句话忽然点醒我,说让我写程序试试。虽然我认为写程序测试没有必要,但尝试从程序的角度思考的话,的确,一开始就选定一扇门,并且无论看到什么都坚持不换,那测试100次,这样选中的概率,跟3选1选中的概率当然是没有区别的。只能是1/3。那么跟这个策略相反的,坚持换选另一扇门的策略,一定能把剩下2/3的情况都吃光。
如果这点不够显然的话,可以假设有兄弟二人一起去参与这个活动,每次都是弟弟坚持不换哥哥坚持换。这俩人一定能包揽所有的汽车,并且弟弟获得汽车的概率肯定是1/3,跟3选1的概率相同。则推出哥哥选到汽车的概率应当是2/3。

我尝试用一个比较显然的方法说服自己,感觉应该是这样。一开始选择了一扇门,这个动作本身将三扇门分为了两份,“我选择了的门”和“我没有选择的门”。主持人在你没有选择的门里面开一扇,说这扇后面是羊。然后问你,你选“我选择了的门”,还是选“我没有选择的门”里面,除了打开不是羊的那扇门之外,剩下的一扇。

如果这样说还不够明白,进一步构造的话。一开始选择了一扇门,这个动作本身将三扇门分为了两份,“我选择了的门”和“我没有选择的门”。主持人不开任何门,直接问你,你选“我选择了的门”还是“我没有选择的门”。一个只有一扇门,一个有两扇门,当然选“我没有选择的门”啦!重新选择了“我没有选择的门”之后,主持人再从那里面找一个是羊的门,打开。这个情况跟先打开再换选,实际是完全等价的。因此换选这个策略能达到2/3的概率,就显而易见了,一个是选了一扇门,一个是选了两扇嘛。

呜,之前的博客中还有对“果壳死理性小组”不屑言论,深表惭愧及歉意。特保持原博客原状,作为对自己错误的惩罚。

掷骰子的上帝 — 冷眼看三门问题

本篇博客观点是错的,我已补新篇谢罪。特保留本篇文章原状作为自我惩罚和警示。

今天基友硬拉着我跟我争论了一个经典的概率问题:三门问题。

问题是说,在机智问答的最后抽奖环节,有三扇门,其中两扇门背后是山羊,一扇门背后是汽车。一旦你选择了一扇,主持人就会选择你没选中的那扇并且打开它。当然这后面一定是山羊啦。这时候你换选另一扇还是保持原来的选择?

这个问题我很早之前就看过,我没多想。再选的概率一定是1/2我认为这没什么可讨论的。但是基友一定要跟我争,而且有一套挺不错的逻辑。我一时说不出他的逻辑有什么错。争论结束我回来还是余兴未央,搜索了一个帖子,是讲这个问题的
换还是不换?争议从未停止过的三门问题~

我努力抛弃原有的想法,尝试理解这种观点。认为换比不换好的人,思路是这样的:
1) 我选了一扇门,后面是羊还是车我不知道,但是是羊的概率是2/3,是车的概率是1/3。
2) 主持人开了一扇门,门后必然是羊;
3) 如果我选的门后是羊,剩下的一扇门背后必然是车;概率2/3
4) 如果我选的门后是车,剩下的门背后必然是羊;概率1/3

这个思路看似缜密实则混淆了概率的基数。
1)和 2)两点都是无可争议的。
我们看第3)点。如果我选的是羊,换门就是车,这也没问题。但问题是,现在我选的是羊的概率还是2/3吗?
当三扇门都未打开时,我选一扇门,门后是羊的概率是2/3,这是没有问题的。但要仔细考虑,为什么是2/3?这个概率是谁贡献的?
不妨设门后的三个物件为:羊A,羊B,车C。
我选一扇门,门后有这三物件任意一件的概率都是1/3,是羊的概率是2/3其实是羊A的概率 1/3 加上 羊B的概率1/3。
当主持人打开一扇门,露出了一头羊,不妨说是羊B吧。这个时候其实你选择到是羊B的概率就是0了!你不可能选择了羊B。
所以可能性只有你选择了羊A,和你选择了车C。所以你选羊A的概率是1/3,选车C的概率也是1/3。你换门得到车的概率是1/3,不换门得到车的概率也是1/3。是一样的。这样说有点不太对,因为是羊B的那1/3的概率已经不可能存在了。整体系统的概率是1。所以说的概率1/3其实是主持人开门之前的概率了,主持人开门观测一扇门后的物件这个动作,其实影响了整个系统的概率。他开的这扇门确定是羊,就说是羊B好了。那么是羊B的概率就是100%,是羊A的概率就是0,是车C的概率也是0。所以剩下两扇门,无论你选了哪一扇,是车的概率都是1/2,是羊的概率也都是1/2。

观测前 门1(羊A 1/3,羊B 1/3,车C 1/3) 门2(羊A 1/3,羊B 1/3,车C 1/3) 门3(羊A 1/3,羊B 1/3,车C 1/3)
观测后 门1(羊A 1/2,羊B 0, 车C 1/2) 门2(羊A 1/2,羊B 0, 车C 1/2) 门3(羊A 0, 羊B 1, 车C 0 )

有人争论说,主持人是上帝,是知道每一扇门后面是什么的,所以他刻意开一扇门的动作,会影响与之相关的孤立事件的概率。让某一扇门变得特殊。但是,这是一个掷骰子的上帝,不是一个决定性的上帝。因为他能知道的只是一扇门后是羊还是车,却不能决定你选的那扇门背后是羊还是车。更进一步的,他只能在你选了羊A的时候打开羊B的门,你选了羊B的时候打开羊A的门。这个“上帝”的选择,其实受控制的。受一开始你选了哪扇门这个“骰子”的控制。所以我说他是一个掷骰子的上帝。这就像是量子理论里面的“量子纠缠态”,当你观测一组纠缠态粒子中一个粒子的状态时,整个系统的状态都被破坏了。

从这个角度重新看这个问题,你选择了一扇门,的确,这个时候门后是羊的概率是2/3。但是主持人打开了另外一扇门,观测结果是羊B。这个观测结果,让你选择的那扇门背后是什么物件这个问题的“量子叠加状态”坍缩了,从原来可能是羊A(1/3)、羊B(1/3)、车C(1/3),坍缩到了羊A(1/2)、车C(1/2)。你会说,凭什么他开门观测到的是羊B,还可能是羊A呢?是的那个可能已经处于另一个平行宇宙了。在一开始你掷骰子选门的时候就决定了(如果你选的是车C,那么这个骰子在主持人决定开门的时候还会再掷一次,这里是有些不同,因为车与羊的不同引起)。

我们回到这个问题的初始,为什么会产生这样的争论呢?其实这不是概率学的争论。任何有点概率常识的人都会算这个概率。其实这是主观与客观之争。

假如你不是参与选择的玩家,而是客观的站在一旁看着。原来有三扇门,每扇门后面是车的概率都是1/3。现在有一扇门是透明的,能清楚看到门后面是一头羊。那么另外两扇门后是车的概率都是1/2。这是无可争议的。
一旦你参与了选择,将其中一扇门特别设定为“我选择了的门”,将其他门设定为“我没有选择的门”,这个时候问题才会产生,以至于“果壳死理性派”都会产生这么多不“理性”的言论。归根结底是人的主观性所致。一旦有了立场,客观的东西就似乎是错的了。这是人类的一大困境。

与此相关的还有量子力学中双缝干涉实验中著名的“观测者悖论”,认为观测结果似乎有可能反过来影响实验过程。这当然是不可能的。就像这个三门问题,难道是主持人打开了一扇门,出现了羊B,才影响了你选择的门背后是羊的概率从2/3坍缩到1/2的吗?其实不是。事实是既然这个游戏规则是一定会刨除一扇背后有羊的选项,事实上你选到车的概率从一开始就是1/2,从来就没改变过。甚至于,主持人开门出现的是羊A还是羊B,很大程度都是你自己的选择决定的:当你选择羊A的门,他只能打开羊B的门;反之亦然。只有你选择车C的门,才稍稍留了一点不确定性。

由于人存在于时间的流动之中,才会对因果律过于执着,对主观的选择和选择的结果过分的看重。所以马塞尔说,“人是时间性的存在”。如果冷眼看之,其实选与不选,本来都是选择,又都相当于没有选择。宇宙运行无非是掷骰子的上帝玩弄着的复杂机械罢了。

程序员日记-银桑

仲春的午后,打开窗户,让温暖的阳光洒进小屋,和煦的春风轻轻抚着泥草香潜入室内,是一种美妙的惬意。

银桑

在这惬意之中,伴随着清脆的雀鸣,打开广播听着怀旧的音乐,品一杯香茗,一只小白猫悄然走上我的窗台,没什么比这更让人感到幸福的了。

我称呼他银桑,跟他初次见面至今也有几个月了。不知是野猫还是隔壁邻居养的,总归经常来玩。我也很乐意奉献些自煮的牛肉汤、鲫鱼汤与他。慢慢跟他熟络起来,如今只要做了饭,在阳台打开窗户,没一会他就会翩翩而至。

猫的性格,可谓谨慎之至。我喂给他吃的,只要是之前尚未接触过的新鲜品种,总要怀疑我是不是害他:我若是怀着期待的眼神盯着他看,他必一副高贵态对香喷喷的牛肉块视若无睹;倘我转过身去,装作对他不在意,却私下里偷眼看他,准看到他急不可待地把鼻子凑过去,三口两口便把肉块吞下。

我在一边慢慢吃饭,他便站在窗台上一副高瞻远瞩的表情,藐视万物。忽然一阵风吹草动,只听咻的一声,以及“咣”的回声许久的金属窗框的哀鸣,待我急忙回头望去,银桑早已在五米开外的草地里了。其多疑与身手敏捷如是。

能在紧张的连续疲劳作战中偶尔有这样一只洁白的小猫陪伴,可谓人生幸事。可惜自己没有时间精力养他,只能尽量惯着他的野性,让他能凭自力在这凄楚的世界中生存。在这一点上,相对于他,我并没有太多优势来着,哈哈。

与一只猫有这一番淡如水的君子之交,若何~

难题:识别独立安卓设备

今天碰巧朋友问到我怎么识别独立的安卓手机,就花了一些时间琢磨了一下。
其实这个问题可以秒答,就是IMEI。


TelephonyManager.getDeviceId();

这需要一个权限:


<uses-permission android:name="android.permission.READ_PHONE_STATE" />

问题如果这么简单就好了,问题在于:

因此其实问题从这里才开始。网上能够搜索到的解决方案有以下几点:

– WIFI MAC

一个方案是优先采用IMEI,当IMEI相同时,再比较WIFI的MAC地址。但如果手机没有WIFI功能或者WIFI功能没有开启(飞行模式),则无法获取到MAC地址。更加让人惆怅的是,我国大山寨厂商实在是懒透了,无线网卡的MAC地址居然也不修改,不少自刷机的也是这病情(例如这个这个还有这个)。至于说蓝牙MAC地址就更别说了。IMEI重复的病因,与MAC地址相同的其实是一个原因,都是刷机或山寨,所以这个wifi MAC地址的方案其实算不上互补了,必须另谋途径。

– Serial NO

另一个方案是用serial NO。这个值仅在android 2.3版本以上才提供支持。通过adb可以这样查看:


adb shell getprop ro.serialno

代码中可使用系统变量android.os.Build.SERIAL访问。如果这个值能够取到这是仅次于IMEI的最好方法了。缺点是这个值在2.2及以下版本的android系统不支持。不过好在如今的安卓世界2.2及以下的占有率已经越来越低了,翻新速度很快,因此这个值很值得一试。

– Android id

其实安卓系统提供了Settings.Secure.ANDROID_ID来获取唯一设备号。


import android.provider.Settings.Secure;

private String android_id = Secure.getString(
                            getContext().getContentResolver(),
                            Secure.ANDROID_ID); 

但同样2.2以前的系统支持得不好。这个值是系统初次启动后生成的,因此恢复出厂设置后这个值会变,导致观测到的设备数虚高。在手机刷机、重置频繁的环境,这个值是不靠谱的。另外某大厂生产的设备居然有个BUG,这个值是会重复的(DROID2),因此这个值还是别用为好。

– generated UUID

最后还有一个自己生成UUID的办法,保存这个ID,每次访问服务器时上传,自己告诉系统自己是谁。这个方法比所有硬件方法都更不靠谱,因为只需卸载软件和清理数据就会导致这个值被删除,从而产生新的UUID,造成观测到的设备数量虚高。更别说刷机和恢复出厂设置了。这个方法非常适合用来统计软件安装次数,而非独立设备数。

结论

综上所述,目前为止我还没找到非常完美的统计独立设备的方案,尤其是在中国这个水货、硬解、山寨、刷机市场泛滥和不规范的安卓世界,更是难上加难。

但是反过来想,是不是一台完全刷新,安装了全新的ROM的手机,就已经不是原来的那台手机了呢?统计独立设备数的目的究竟是什么?如果要的是独立活跃设备数,其实用自己生成的UUID已经足够,因为原来使用的那个UUID已经失去活性,可以忽略了。对于APP开发者而言这个情况与用户换了一台手机,完全弃用旧手机的情况其实是一样的。假如是采取活跃UUID的方式,则即使是使用ANDROID_ID或者自己生成的UUID都是可取的做法了。

本文参考

除草

好久没写博客了,最近发现博客访问超级慢,过来除除草。

chrome的开发者工具—network帮了大忙了,很容易就分析出加载慢的原因。原来是坑爹的gplus插件已经被墙了。加上friend connect也没什么人用,也很影响速度,干脆删除掉了。另外就是首页加载时,去年放上去的好几张很大幅的照片超级影响性能,放到more分割线后面去了。

奇怪之前hostmonster的国内访问速度一直挺靠谱的,不知最近怎么变得这么糟了。不过处理了几刀子之后总算可以访问了。

简单写两笔,也算除除草吧。新年新气象,要多钻研技术多写博客,继续精进才行啊!自勉。

北京堵车考

荒废好久的博客。。俺回来鸟。
又是出差北京,体验北方冬天的干冷。

在出租车上堵得无聊,就跟师傅闲扯。我很呆地问:“这五环上又没有红绿灯十字路口,所有的车都往前开,照理说车再多也不可能堵车啊。”
师傅回答:“人多事儿多呗。抽口烟,喝口水,旁边撞车了踩脚刹车看看撞得咋样儿。可不就堵了么。”
“哦。”

原来高速路上也能堵车,是这么个理儿。

果然磨磨蹭蹭挪了20多分钟,前面有个撞车的。过了那辆车,前面一大段路都是一路畅通了。真的很有意思,因为没有岔路,主干线上仅仅一处事故就能引发整条高速路的拥堵。由于人多车多,这偌大的五环上只要有那么三五处事故,就能全天二十四小时不间断堵车了。

如果真是这么有趣的原因导致堵车,那么解决方案似乎也很简单啊。最极端的方案就是全面实施自动驾驶。上高速路不算,进了路,速度平稳之后,必须切换到自动驾驶。这自动驾驶首先不会出事故,更不会因为旁边有事故现场就减速看热闹。这么一来五环的运力就可以用一个简单公式计算:车速×车道 / 车距。根本不可能堵车嘛。

当然短期内还不可能全面实施自动驾驶,那么稍微简单点的办法就是通过广大司机们的自觉。说劣根性那是没办法,但矫正总还是有机会的。哪个北京司机不骂北京交通的,哪个司机不想早那么一点到目的地的。如果大家都知道,就因为自己多踩一脚刹车,晚起步半秒,导致的蝴蝶效应正好绕五环一周,叠加在自己的堵车时间上,那么为了快每个人在五环上就更冷血点,更严肃点,更快更少小动作点,事情不就解决了嘛。

这跟市内交通还不一样。毕竟在五环上,没有十字路口没有红绿灯,大家都往一个方向走,并且除了特别的时间段,通常来讲上五环和下五环的车数是相等的(除非有车想赖在五环上就不下来了)。所以只要大家都快起来,五环自然就不会再堵了。

另外可以提建议的,就是不如砸点钱搞几架直升飞机支持高速路上的事故处理。你派拖车过去把事故车再运走,一天时间都没了,可能保险公司来调查的人还堵在半路呢。直接直升飞机把该来的各方面人员都带过来,一股脑解决,把事故车吊走,至少吊离现场把,运到附近公路上再慢慢等拖车呗,能解决多少运力问题。那烧在路上的时间,分分钟都是钱啊,光节约的油钱就够多少架直升机了。

ftp 客户端小心得

很少用到命令行的FTP工具,今天用到,碰到点问题,记录一下。

ftp批量上传的命令是mput。但是mput /…/path/file 会报invalid file name 错。具体没有细究,网上查下来,似乎mput命令后面不能带路径,可能是filezilla自己的问题。我并没有多想解决方案,而是按照网上的说法,先cd进目标路径,再mput *,解决这个问题。

另外,进防火墙的FTP服务器,需要用passive模式,这点以前没注意过。
最后就是ftp的prompt命令可以实现无交互。