Screen 是用另一个比较轻便的终端复用工具，[[Tmux]] 可以参考另外一篇文章。Screen 让用户可以在一个终端中开启单独不同的 “screen” 终端窗口来使用。我们都知道使用 ssh 连上服务器之后如果因为网络问题终端了当前连接，那么正在执行的任务也会因此中断，所以我们可以将长时间的任务放到 Screen 中执行，即使因为网络问题断开了 SSH 连接，再次使用 SSH 连上之后也可以轻松的恢复之前的任务。

Screen 让用户之前也可以分享 Session，只要 Screen 状态存在，其他用户也可以 detach/attach 到相关的 terminal Session 中来实现分享。

至于为什么有了这篇文章呢，是因为之前登录要一些机器上，发现并没安装软件的权限，所以安装不了 tmux，而发现系统中自带了 screen ，所以就学习一下。如果使用过 tmux 那么 screen 也是非常简单的。

安装

sudo apt install screen

使用

使用 Screen 非常简单

screen

这是会进入 Screen 创建好的环境。使用 Ctrl-a 在加上 ？ 可以查看所有的快捷方式。

下面介绍比较重要的几个快捷键

新建 screen

通常情况下只需要 screen 新建匿名的 screen 即可，如果需要给 screen 命名可以使用

screen -S name

detach / attach Screen

Ctrl-a  d          detach screen 用来从 Screen 中脱离

需要重新连接则使用 screen -r

如果有多个 Screen，则需要使用 screen -ls 来查看 Session 的 ID。然后 screen -r id 来 attach。

修改 screen session name

如果在 screen session 内部，使用：

Ctrl + a 然后按下 :sessionname new_name

注意这里的 Ctrl + a 是 screen 的 prefix, 还有命令之前的冒号一定要加。

如果在 screen 外

screen -S old_name -X sessionname new_session_name

上面两个方法可以修改真正的 session name 但是在并不会修改窗口的名字，如果要修改界面窗口的名字则需要

Ctrl + a 然后使用 Shift + a 再输入名字，则能够修改窗口显示的名字

切换多个 Screens

Ctrl-a n        下一个 screen
Ctrl-a p        上一个
Ctrl-a 0-9
Ctrl-a space    按 0 - 9 顺序切换
Ctrl-a w        显示所有窗口列表
Ctrl-a c        创建新的
Ctrl-a k        杀掉 screen

Copy 模式

类似 Tmux ，使用 Ctrl-a [ 进入 copy 模式，在 copy mode 下可以复制，搜索等等，类似 vim

Ctrl-b      PageUp
Ctrl-f      PageDown
0           行首
$           行尾
Space       标记起点，第二次标记结束
Esc         结束 Copy 模式

Ctrl-a ] 粘贴，可以将 Copy 模式中选定的内容粘贴上。

高阶

screen 可以在 /etc/screenrc 和 $HOME/.screenrc 两个文件中添加更多的配置。比如绑定快捷键，设定启动窗口，用户控制等等。

reference

• https://www.tecmint.com/screen-command-examples-to-manage-linux-terminals/
• https://unix.stackexchange.com/q/27780/115007

百科解释

维基百科上面的解释，百毒百科大概的解释也类似

在现代标准汉语读音里，有两种分歧：一种读嫖（piáo）《汉语大词典》；另一种读朴（pú，注音：ㄆㄨˊ）。中国大陆一般取前者，而台湾则取后者。

按《广韵》记载，该字“普角切”，按中古音到北京音的演变规律推导，应该读如po。韩语中“普”读作보（po）；“角”读作각（gak），“朴”读作박（pak），符合中古音向汉字韩音的演变规律。而一些保留入声的汉语族语言如粤语、闽南语等也读如“朴”。

在古代，所有情况下“朴”的发音都是“普角切”。唯一的例外是作为姓氏。“朴”姓非汉族姓氏，三国时代有夷王“朴胡”。《文选》陈琳《檄吴将校部曲文》有“巴夷王朴胡、賨邑侯杜濩各帅种落，共举巴郡，以奉王职”。《三国志·魏志·武帝纪》有 “建安二十年（公元215年）“九月，巴七姓夷王朴胡举巴夷来附”。《集韵》注云:“披尤切。夷姓也。”可见在当时作为姓氏，“朴”的发音与一般情况下不同。但是第一，即使披尤切，中古拟音phiu，按演变规律今天普通话也应该读作pou；第二当时的朴姓与后来新罗的朴姓未必同源。因此piao音在音韵学上无可信依据。有一说法则认为是朝鲜语固有词“박”的意译“瓢”（piáo）。

我没有找到任何证据显示说“朴”字的发音应该念成piao，维基中也提到一句，“piao音在音韵学上无可信依据 ”。于是我继续寻找证据，说文解字中的解释

從木。卜聲。

匹角切。三部。按凡鞭扑字從手作扑。卽攴字也。凡樹皮字從木作朴。凡棫樸、樸屬字作樸。卽㯷之省也。凡朴素字作樸。皆見說文。

同样没有任何证据显示“朴”字念piao的音。而我无意中找到这样一篇文章，文中作者同样也对piao的音提出了疑问，而其中作者引用了一段维基中的原文，而和我读到的维基原文竟然有了一段话的偏差

根据朝鲜半岛新罗的开国君主、朴姓的始祖赫居世的传说，相传赫居世是从天上飞来的白马生下的紫卵中出生的，卵形同瓢，所而取姓为朴。朴是朝鲜语“박”的音译。박意味瓢。 (按：”호박”이라는 “박”)

在中文读音里，有两种分歧：一种读嫖（piáo）《汉语大词典》；另一种读扑（pū）《资治通鉴》。中国大陆一般取前者，而台湾、香港则取后者，依据名从主人的原则，朴读作扑比较合理。

按《广韵》记载，该字“普角切”，按中古音到北京音的演变规律推导，应该读如po。“普”韩语读作보pu；“角”韩语读作각gak，“朴”韩语读作박pak符合中古音向汉字韩音的演变规律。

估计当年中国审音委员会为“朴”做普通话审音的时候犯了技术错误，“普”普通话读作pu，“角”普通话读作jiao，于是“朴”就审定为piao，而忽视了“角”的颚化介音i是由于受古声母g颚化为j的影响。“朴”不应该引入这个介音i。河北枣强县朴庄，当地口头都说成“炮庄”，不带介音i。

这段文字中提到的中国审音委员会一段在如今的维基百科中被删去了，虽然也可能是维基百科中对来源的准确要求，但是却大大影响了对朴字发音的理解。所有的一切都有了解释，piao的发音都是当年中国审音委员会的一次“错误”。更加重要的是该文中提到的另一段证据确凿的文字。引用如下

专业解释

“朴”字的音

主题：“朴”字的音(1)

版权所有：了了斋 原作

提交时间：08:52:37 08月07日

[按] 【我本来也是跟兄一样，想等方言的材料说明这几个音的关系。看来不容易。也许大家和你我一样，都是平时只用“朴素”的音，其它的音是从字典上查出来的。我是既没见过朴树，也没吃过厚朴。姓朴的也只知道是朝鲜族的大姓，可是说实话，我还没遇到过姓朴的呢。想兄暂时还一筹莫展，我就先走一步，试着回答一下。请兄海涵。

我现查材料现写，请大家随时补充修正，也寄希望有方言材料随时补充上来。请版主原谅冒昧.】

“朴（繁体）”在《广韵》里出现在 4个地方，分别是：

（1）模韵，薄胡切：“朴澴（不是水旁，是立刀旁），县名，在武威。澴音还。”折合今音是pu2。
（2）屋韵，蒲木切：“《尔雅》云：漱（不是水旁，是木旁）朴，心。又音卜。” 折合今音是bu2。
（3）屋韵，博木切：“域（不是土旁，是木旁）朴，丛木。又音仆。朴域，小木也。”折合今音是bu3。
（4）觉韵，匹角切：“木素”。后面要论证，这是今“朴素”的来源

所以我们暂时定音为pu3。

另外，《广韵》也收了“朴”（简体），在觉韵繁体“朴”的后面：“朴，上同。又厚朴，药名。”

这里面，（1）-（3）都是复音词中的音，不知道是从什么路数上来的。看得出，有根底而且与今音有关的是（4）。

（注：《尔雅》一句，通行的断句如此。似不通。望通人教我。）

主题：“朴”字的音(2)

版权所有：了了斋 原作

提交时间：06:34:00 08月08日

《现代汉语词典》的“朴”字有4个音，出现在下面的说法里：
（1） po1，朴刀。
（2） po4，朴树。朴硝。
（3） piao2，姓。
（4） pu3，朴厚，朴陋，朴茂，朴实，朴素，朴学，朴直。
另外，《字典》给“厚朴”的注音是po4。
可以看出，pu3是活棋，其他都是死子儿。

主题：“朴”字的音（3）

版权所有：了了斋 原作

提交时间：07:18:17 08月09日

《辞海》也是4个音，同《现代汉语词典》，不必罗列。
不过，《辞海》是百科辞典，它要照顾古今。所以《辞海》在pu3下列有从古至今的不同义项。我们看一看这些义项：

（1） 树皮。《文选·王褒〈洞箫赋〉》：“秋蜩不食抱朴而长吟兮。”李善注引《仓颉篇》：“朴，木皮也。”
（2） 未经加工的木材。《论衡·量知》：“无刀斧之断者谓之朴。”
（3） 原价，本钱。《商君书·垦令》：“贵酒肉之价，重其租，令十倍其朴。”
（4） 敦厚；质朴。《孔子家语·王言解》：“民敦俗朴。”陆机《羽扇赋》：“创始者恒朴，而饰终者必妍。”
（5） 老子用语。指原始自然质朴的存在，即“道”。……

第一项是皮相之见。秋蜩抱朴，它不抱在树皮上，难道还能抱在树心里？这句话不过是说，在肃杀的秋风里，寒蝉抱在木华脱尽的败枝上（所以叫“朴”）长鸣不已。“刀斧之断”就是加工，加工之前就是“朴”。所以“朴”才能成为变化之本，才能后来“十倍其朴”。开始的时候只有“朴”，后来“十倍其朴”就“妍”了。老子当然是希望去雕饰，归真朴。所以，归结起来，“朴”的意义就是“未经修饰之前的原本”，其它是这意义上的延伸。

主题：“朴”字的音（4）

版权所有：了了斋 原作

提交时间：19:55:57 08月10日

《广韵》“木素”的说法来自于《说文》：“朴，木素也。”“素”指没有修饰，原始的；“朴”是“未经修饰的原本”，“朴素”是近义词的合成。前引《广韵》四个字里，只有这个字是它可能的来源。可是问题出在“木素”的“朴”来源于觉韵，就折合来说，不应当是“pu3”，而应当是“po”（声调不可折合，我们后面再说。）

“朴”字以“噗（没有口）”得声。从前面引的《广韵》里就可以看出，四个字里有两个都是“屋”韵，而不是“觉”韵。翻开《广韵》更可以知道，这个声符的字在“屋”韵里的跟在“觉”韵里的完全不成比例，加上“沃”韵和“烛”韵的就更多了（今天可以同韵）。下面把字引在下面，不需要认识，可以有一个概略的印象（以下用 + 号代替这个声符）:

屋韵：
蒲木切：+毛，人+，臣+，矢+，+，禾+，木+
普木切：酉+，土+，禾+，手+，+鸟
博木切：水+，阜+，车+，女+，木+，犬+，足+，丝+，衣+，髡+，革+
沃韵：
蒲沃切：人+，臣+，金+，虫+，车+，+鸟
烛韵：
房玉切：幞，衣+
封曲切：革+
************
觉韵：
蒲角切：手人+
匹角切：璞，木+，牛+，土+

这就难怪了，觉韵的5个字，怎么能抵挡得了屋韵的32个字。而且，无论是繁体“朴”的谐声，还是简体“朴”的谐声，都是在“屋”韵（卜是博木切）。可不，今天的事实也是大家能认得的“璞”和“朴”都念屋韵了。

（周末我休息，提前发表。星期一再见。）

主题：“朴”字的音（5）

版权所有：了了斋 原作

提交时间：11:59:11 08月13日

有人说，语音的特点就是“习非成是”。这话不假。前一阶段大家都因“呆dai”“呆ai”二字语音合并而议论纷纷。这二字原来的意义是有差别的。ai是死板，死心眼的意思；dai是发愣，精神不正常的意思。一个人死板，不一定发愣；一个人是呆子，看问题可不一定死板（多数时候，他不看问题），有时候呆子还会突发奇想。可是“呆子”是书面上常见字，ai是口语字，现在的读书人又不常说这个词，最后dai 的音就战胜了ai 的音。（读书人也不见得不说ai，我有一回在课堂上听见周祖谟先生说，“看问题也不能太ai了。”而且周先生的发音前面还带有声母ng。不知道是北京话的底层还是周先生特有的地方口音。可惜一代鸿儒，转眼之间就不在了，求教无门。）dai、ai合一是最近刚刚发生的事，众情汹涌。有些是历史上的事，人们也就安之若素了。举个例子来说，“三分之一”现在大家都读“fen1”，其实这个字本念“fen4”，浊声母。吴语区的人大概还能分出来。意思是三份儿里的一份儿。现在大家按“分”理解，好像也讲得通，然而终究不能那么妥贴。不过硬要讲妥贴，也未免太ai了；可是全然不去动脑筋，不就成了“呆子”了？（我没有责怪的意思——难得糊涂，也许是一种大智。）

“习非成是”也不是说故意乱念就可以，这与契机有关。其中最重要的是力量对比。寡不敌众，优胜劣汰。从前，李白念李bo2，它怎么能顶得住白菜萝卜，白布红旗。李“伯”也就只好让位于李白了。“朴”字的音，按语音折合该念“po”，现在大家都念“pu”，这是无可奈何的事。况且这件事是由来已久的。觉韵的这几个字到了宋代的《集韵》里就多数有了屋韵的异读，甚至连“朴”(简体)也有了屋韵的读法。所以现在还想复辟旧音，也就太ai了。

补充：《尔雅》郭注有一个地方说明“雕”等五个词时说：“五者皆治朴之名。”可证“朴”确实是“未治”之前的东西。

（写到这里，我想看官也看累了，我也写倦了，pu3的音正好也讲完了。再写似乎腻味。暂时告一个段落吧。）

主题：“朴”字的音（6）

版权所有：了了斋 原作

提交时间：10:42:51 09月04日

（有始有终吧，我还是把这《“朴”字的音》写完。不过，以下所写，多少有一点学术性了，不能不表一些态，有说错的，有伤着的，请多包涵，也欢迎据理力争。）

其实，不但“朴素”的“朴”来源于“匹角切”，就是其他3个音也来自于这个反切。《广韵》的四个音，只有“匹角切”可以念“o”韵，其它的音只能是“u”韵。从那几个死子儿的读音被一分为三这件事可以看出，编字典的人大概和我们一样，根本就不知道那3个字念什么，只是依样画葫芦，查字典画出了那3个音，可惜画成瓢了。

“朴刀”我没有见过。从《现代汉语词典》的描写来看，大概就是一种没有修饰的，抡起来方便的实用刀。取名之由就是取其质朴的意思。

“朴硝”通称“皮硝”，是用来“硝皮”的。按《辞海》关于“朴硝”的说明，粗制的“朴硝”叫“皮硝”，精制的“朴硝”叫“芒硝”，可知“朴硝”的说法是相对“芒硝”而言的，也是取其“未治”的意思。

“厚朴”倒很简单。《广韵》收了这个词，就在“匹角切”的繁体的“朴”的后面。可是就连《广韵》已经注明“上同”的“朴素”的“朴”字都已经跑到了“u”韵，它又为什么要读“o”韵呢？

“朴”姓既然是姓，又不是一个常见姓，除了姓那个姓的人，别人也就不知道那是什么音了。我们后面要说明，其实那个音也是来自于“匹角切”。

既然它们都来自于“匹角切”，又为什么要被四分五裂呢？这根源于“朴”是个入声字。定音人吃了个烫山芋，心里烫的没抓挠，脸上还得装镇定。

主题：“朴”字的音（7）

版权所有：了了斋 原作

提交时间：07:38:41 09月05日

“朴”来自于入声，入声在官话区的中心地带是一个已经死亡了的调。

可是入声是国粹，也是士大夫摇头晃脑的资本。俞敏先生曾回忆说：旧时念《大学》是“大学xue4之道dao3，在明明德de4”（《李汝珍〈音鉴〉里的入声字》，《北京师范大学学报》1983年第4期）。“学”和“德”是入声字，可以看出，为了保存国粹，我国的士大夫是多么地甘冒佶曲聱牙于不顾。可是士大夫可以在念唐诗的时候念李白bo2，可是到了饭桌上，他也不敢把白菜说成“菠菜”。所以，这只能是一场闹剧。

天不作美，古入声的清音入声字在北京话里散入四声，没有规律可循。现代科学的研究法传入我国后，人们试图找到规律。最早有白涤洲先生的《北音入声演变考》（《学术季刊》第2卷第2期，1931），后有陆志韦先生的《国语入声演变小考》（《燕京学报》第34期，1948），走的都是统计的路子。白氏的结果是不送气清入归阳平，送气清入归去声；陆氏的结果是不送气清入阴平阳平差不多，送气清入归入阴平的更多。这真叫人哭笑不得，本以为数字总是客观的，没想到连这所谓客观的数字也靠不住。

另一条路子是领悟的路。这当然最好的成果是平山久雄先生的《中古汉语的清入声在北京话里的对应规律》（《北京大学学报》1990年第5期）。平山先生发现，凡动词念阴平，名词念上声。不用说，这是了不起的发现。（真正的发现就是那种谁都看得见，可是谁也不知道；等到发现后，大家又觉得没有什么了不起，放在谁也发现得了的那种东西。——我曾经把这项成果告诉马希文先生，马先生感慨地说，他从各个角度对入声字做了统计，就是没有从这个角度统计。马先生是五十年代北京的神童，七十年代我国863计划的主持人，八十年代我国计算语言学的开创者。马先生是一位不懈的追求者，也是计算机专家。可见智者千虑，也有偶失的时候。而不讳言误失，才不失科学家的本色。去年马先生往生它界，谨此纪念我国这位真正的科学家。）的确，我们只要把字列在下面，大家谁都会看得出来：

吃喝说挖刮揭拍戳擦掐贴塞劈刷滴泼扎杀歇织哭出……

脚角骨铁血曲谷雪宿(xiu3)柏塔法色(shai3)室(shi3)…… 事实胜于闭着眼睛的方法。这个结果无疑是对的。（我一点也没有否定方法的意思，我否定的是闭着眼睛的方法。我在一篇文章中说过，方法是客观规律的对应物。如果你拿来一种方法，居然可以解决问题，那只是说，那个事物的规律还没有用这种方法解决过，不是说那个方法是万能的。）——不过，就我的看法，平山先生对形成原因的解释还不能令人首肯，至少未达一间，有一个结还没有解开。目前这个发现是2+1=1，还不是1+1=1，希望有志于此的能最后解开这个语言学领域里的哥德巴赫猜想之谜。

这就决定了，“朴”的声调不可能折合。那么，“朴”的那些奇奇怪怪的声调又是怎么来的呢？

（注：“方法是客观规律的对应物”这句话不是我的发明，是我从课堂上听来的。可是老师也忘记出处了。向各位请教，有谁知道这句话的原出处，感谢不尽。——niina如何？）

主题：“朴”字的音（8）

版权所有：了了斋 原作

提交时间：07:16:38 09月06日

“朴刀”的“朴”是第一声，就先从它说起。

给“朴刀”定第一声，是知其不可为而为之。编字典，你总要给一个字定一个音，不能因为不知道而空着。这是没办法的事。

为了给清音入声字定音，普通话审音委员会有个规定：“古代清音入声字在北京话的声调，凡没有异读的，就采用北京已经通行的读法。凡是有异读的，假若其中有一个是阴平调，原则上采用阴平，例如：“息”，“击”。否则逐字考虑，采用比较通用的读法。”

所以，我估计，这个阴平调就是在这样的原则下决定的。

主题：“朴”字的音（9）

版权所有：了了斋 原作

提交时间：07:17:46 09月06日

“朴树”“厚朴”念去声，可是个开玩笑的音。

北京话没了入声，可就难坏了北京的读书人。——放到现在这网上，当然没问题，有人不是特别看不惯咬文嚼字吗？（不过你别看他在网上装潇洒，错别字满篇，真要给他填提职的表或者申请奖金的表，他恨不得情人给他当校对呢！）——可是那年头的读书人要做诗，还要押古韵，不知道入声这辈子别想得功名，于是就有了一个上不了台面的理论：入声通通念去声。这就是第（7）节一开头演出的那一场俞敏先生说的闹剧。这和前面说的“原则上采用阴平”可以说是异曲同工，或者用现在的时髦说法，刚好是一、二、三、四的“镜像原则”，两个极端交相辉映。这也就是为什么“厚朴”“朴树”念去声。

主题：“朴”字的音（10）

版权所有：了了斋 原作

提交时间：07:19:16 09月06日

“piao2”是“朴”姓的专用音。朝鲜人根本不念piao2，而是念pak。如果让汉人听起来，就是“pa”，根本听不成“piao2”。

其实这是北京话的老土话。“朴”字来源于“觉”韵。“觉”韵和“药”韵“铎”韵在中原地区念“o”韵（及其变体“e”韵），北京就念成“ao”韵。比如中原的“落luo”北京就念成“lao”；中原的“药yue”北京就念成“yao”；中原的“学xue”北京就念成“xiao”；中原的“觉jue”北京就念成“jiao”；中原的“郝he”北京就念成“hao”；中原的“弱ruo”北京就念成“rao”；中原的“着zhuo”北京就念成“zhao”；中原的“薄bo”北京就念成“bao”。当然了，中原的“朴po”北京就要念成“piao”了（以上举例里，“学、觉、朴”是同韵字）。北京人和东北人是一路的。北京人和东北人见过朝鲜人，这是他们的骄傲和自豪，他们说朝鲜人姓“piao”，别人还敢说什么，这不，《现代汉语词典》也就把“piao”收进来了。

主题：“朴”字的音（尾声）

版权所有：了了斋 原作

提交时间：07:08:48 09月07日

我要说的也说完了。要问我“朴”字该念啥，在我看，就是一个音——“pu3”。只有这是历史演变的自然结晶，其他都是人工的。为什么这个音会是活棋，其他的都是死子儿？很简单，因为它秉承了天地正气。你瞧，它的声调也刚好是合理的：“朴”是“未治”之器，名词，它该念上声。而其他的都是定音人的私生子，连声调也是没来由的。有人说，声调是汉语音节的灵魂——瞧那个“朴树po4shu4”，这不是诅咒那个树呢嘛，小心烂舌头！至于那位歌手，我想他一定愿意听人叫他“pu3shu4”而不愿意让人骂他“po4shu4”。我猜的不会错吧？

不过，我可得声明，如果大家要参加高考，还得写4个音，而且不能张冠李戴了。为啥？考官是他不是我。好在我写了这么多，大家也把这几个糊涂音的糊涂法儿记熟了，就算是我对传播这4个音当了功臣——如此想来，那4个音的制定者不会怪罪~我~吧~！

（补1：古反切折合今音，常常把人绕到五里雾中。不过“匹角切”倒是刚好切出来是“piao”。）

（补2：我估计“朴刀”就是大刀。“大刀”做专有名词不大好，所以叫“朴刀”。另外，古汉语直至近代汉语，“朴”应该是一个活跃的词。古代有“朴马”“朴牛”“朴猪”一类的说法，有人释为“大”或者“未经调驯的”，错！这是指未骟的，即今天的种马、种牛、种猪，也是“未治”的意思。（不过古代的用处大于今天，不能用“种”这个字眼，今天人类自大无比，可怜的动物也就只有这个作用了。）今天“朴”字已经退居“词素”的位置，所以上面所说的“活棋”也已经是半活的棋了。）

——全文完——

整段文字引用自《北京大学中国语言学研究中心》，很可惜，这个网站在我访问的时候已经无法访问，我不清楚为什么，最后只是简单的利用Google Cache找到了一些源头。

而我尝试访问中华人民共和国教育部网站，想探寻一下当年审音委员会的文件(关于《普通话异读词审音表》的通知)的时候，它告诉我栏目正在维护中，不了了之。而在其他网站

現在從字典到《辭海》，冷僻字都有大量錯音，主要原因是盲目用現代讀音套古字典反切，罔顧音系演變的其他規律。擧個例子：

“朴”審為piao2。按《廣韻》記載，該字“普角切”。估計當年中國審音委員會為“朴”做普通話審音的時候犯了技術錯誤，“普”普通話讀作pu，“角”普通話讀作jiao，於是“朴”就審定為piao，而忽視了“角”的顎化介音i是由於受古聲母g顎化爲j的影響。“朴”不應該引入這個介音i。

韓國姓“朴”讀作pak，是符合“普角切”在韓語中的演變規律的。那麽普通話也應該考慮“普角切”這個中古音節在普通話中是怎麽轉變的。還有個可能性是根據《集韻》“披尤切，音䬌。夷姓。” 用現代音，披pi2尤you2切出piou2，piou3不符合北京音系，就用近似的piao2。還是錯！

来自新一届普通话审音委员 北大中文论坛。

总结

因为最近看韩语发音，明明“박“的发音和pu相近，就是不明白为什么要生生的翻译成piao？韩语与汉语的渊源大家熟知，而我却一时迷失了，搜罗这么一大段文字，也许没有人能完整看完，而我也并不是自证pu发音的正确性，只是简简单单的感慨一下，历史时代的变迁或多或少的影响着后世的发展，文字的发音会因为一次阴差阳错的制定而变得如此可笑，而这更让我想起了《1984》中描写的对语言的改造，这一切也并不是不可能，既然发音可以变，那为什么含义就一定是那个含义呢？难道不会是后人赋予的某个含义么？如果没有人去考究，亦或是将原始资料全部焚毁，后人还知道吗？而这一切不也正是GFW正在干的事情，将一切不合“规定”的言论立即删去，把所有的言论圈在局域网内，让人无法考证，或许以前我们还能有纸质的文档可以保留下来，而如今大部分的资料都是电子形式，很久很久以后，我们还知道我们说的那个东西确确实实是那个东西吗？

记得很久以前看霍炬的一篇文章，其中说到一句，“Google给我们的最大价值，除了信息流动加速，就是信息永存，当写完一篇博客，点击发布之后，无数的蜘蛛就会把这篇文章复制若干，存在世界的各个角落。这些言论无法被某个组织控制或删除，也无法阻止其流动。”看到这里的时候，我就被深深地触动了，这是霍炬热爱Google的原因，同样也是我热爱Google的一大原因。回到朴字发音的问题，我当时问的时候，大部分人回答的是“朴树”念做“pu3shu4”，而事实上“朴树”念做“po4shu4”汉典，这是现代汉语字典定义的，“朴信惠”念做“piao2xin4hui4”，而事实上，我认为应该念做“pu3xin4hui4”。至于谁对谁错，又有什么意义呢？

参考

• 普通话和国语之间的差距
• 《廣韻》xml版

是时候告别朋友圈了，一遍一遍的告诉自己，曾经关闭过很长一段时间的朋友圈，后来又开启了，用过这段时间之后还是选择关闭。关闭之前说过推荐 10 部不得不看的韩国电影，今天推荐完最后一期，也就是最后关闭朋友圈的时候了。

内容匮乏，互动缺失

微信固有的封闭模式导致了微信产生的内容的局限性，原创的内容匮乏，朋友圈中充斥着转载文章，剩下的就是晒吃晒喝晒自己，而对于我，微信的审查机制导致部分文章在我看到之前就已经被删除，白白浪费我加载的时间，其他内容很少找到我感兴趣的，对于各种晒的，其实我也并不是太关心今天吃了什么，喝了什么。而互动性来说，微信是所有 SNS 中最封闭的，有时候会在网上随意浏览看新闻的时候看到微信朋友圈中的截图，并以此作为一个新闻，这时我会想，到底是哪个朋友出卖了在朋友圈中发表内容的人，就像前段时间网上流传的毕福剑的视频，原本只是朋友酒席上一番玩笑，却被拿到大众面前，我深深的为毕福剑有这样的朋友而感到悲哀。对那些想要堂堂正正发表新闻的人来说，获取别人通过公开渠道发表的内容才是对别人的尊重，如果当时发朋友圈的那个人只是想在朋友间发表内容，那作为他朋友圈中的一名，至少应该得到当事人的许可才能将朋友圈的内容公开，这是最基本的尊重。

而朋友圈最大的问题在于互动的缺失，正像之前看到的文章 —-“新技术真能带来变革吗？”一文中提到的，微信对于公共议题的讨论连微博都比不上。朋友圈中的大部分都是内容的消费者，而大部分的内容生产者都是抱着强烈商业目的的，都是想着向你卖东西。而少数剩下能够讲实话说真话的内容早已经在别人分享到朋友圈之前就消失在了微信的平台上。

即将泛滥的广告

随着微信用户量的增大，微信变现的方式也会越来越激烈，就前段时间还开放了广告自助平台，朋友圈的广告泛滥的结果可想而知，虽然目前朋友圈的广告并不是很多，大部分的广告也并不是很讨人厌，只是我天生的广告洁癖让我无法忍受。

朋友圈中的信息孤岛

或许有些人会反问我说，他们只是在碎片的时间中刷刷朋友圈，而我会回答他们，关闭朋友圈之后我会利用碎片的时间阅读 RSS，有着开放的互联网可以值得我去拥抱，为什么我还要看朋友圈那一点点和整个互联网脱离的孤岛。我宁愿在闲暇的时间看他人博客上经过长时间思考写出的文章，宁愿看 Google+ 上对于某个问题激烈的讨论。我关闭朋友圈的另外一个原因就是经常看到不经过大脑思考就转发的内容，就如之前的“贩卖孩童一律死刑”的转发，虽然我的朋友圈中父母亲并不是很多，但也依然看到了不少的转发。虽然我也并不能有任何指责，拐卖孩童本身就是一件很严重的违法事件，至于判刑，如果真像大家所说的那样呢？那件事情之后我看了很多的文章，有讲到美国儿童失踪之后的警方处理流程，有讲到法律判刑的基准，有讲到民意等等的，只是那些文章我都不是在朋友圈中看到的，朋友圈中终究没有人认真的讨论这件事情，而是无休止的引发着仇恨。

最后

终于有勇气关闭朋友圈，也再没对朋友圈有何留恋了。

参考

• 新技术真能带来变革吗？
• 对《该判死刑的不是人贩子，而是“民意”》一文的一点看法
• 美国如何防止拐卖儿童：三名孩子改变美国历史
• 媒体：“人贩子全部死刑”是挑战司法公正

引子

最早接触韩国电影是很久之前的我的野蛮女友，当时地方电视台播放过，那是我印象当中最早看过的韩国电影了，也是为数不多重复看过几遍的电影。说到韩国电影不得不提他们的OST（电影原声），我的野蛮女友让我记住了 I believe 的旋律，而 I believe 的旋律也让我一遍一遍的回想起电影中的情节。这或许就是音乐的魔力，在关键场景播放出动听的背景乐，不仅能够让调动观众的感情，也能让观众在过后听音乐时回想起电影中的一幕幕。曾经有同学和我说过，“有些歌一遍一遍听，听到最后就没有意思了”，其实这个时候我想告诉他，他没有体会到歌声背后发生的故事，听这首 I believe 的时候，会想起牵牛第一次遇见全智贤的时候，会想起他们在山头的喊话，会想起他们无数次的错过，最后有神奇般的相遇。

而如今想起整理10部不得不看的韩国电影关键是最近看韩国综艺较多，而其中《蒙面歌王》让我改变了对韩国文化的看法。《蒙面歌王》中有一句话说的很好，“摒弃一切偏见，参加比赛”，也正是这个节目让我寻获了很多好听歌，同时也认识了很多的实力歌手，也正是这个节目让我意识到我是不是一直对某些方面存在偏见，我是不是曾经看到韩文，看到日文就无意识的忽略，我是不是曾经对某些品牌，比如联想，存在固有偏见，我是不是曾经对某些方面的认识带有一种倾向。思考良久之后，我觉得我要整理整理我曾经看过的韩国电影， 从电影这一个部分去体会这个和我认识中的存在偏差的韩国。可能大部分的人对韩国的认识都是“棒子”，“中国节日的盗窃者”等等，虽然历史上可能韩国人做过一些坏事，可是几百年过去了，韩国早已跨出一大步，无论是在经济，还是在政治，还是在文化产业上都遥遥领先中国。而我们还在称呼他们“棒子”以为占得一时便宜，占得一时口舌之快就能在现实中超越人家。我们太天真也太傻了。有人说过，”偏见有的时候比无知还要可怕，就像你永远无法叫醒一个装睡的人”。

大部分人接触韩国电影可能都是从爱情片开始的，而看过的韩国爱情片并不是很多，继我的野蛮女友之后，看的第二部爱情片好像是建筑学概论，当然同样，这部电影让我记住了《记忆的习作》一曲，虽然现在剧情有所遗忘，但是如果此时想起《记忆的习作》一曲我依然能够辨识出来，也会想起电影中的一两个镜头。当然，虽然建筑学概论是一部好电影，但还远远没达到我要推荐的韩国电影的水平。近10年的韩国电影发展迅速，各种类型的片子都能找到一些，而我整理出来的10部片子中既包含了爱情片，同样有故事片，现实题材影片等等。10部影片分别是《熔炉》，《辩护人》，《素媛》，《7号房的礼物》，《流感》，《我的野蛮女友》，《杀人回忆》，《老男孩》，《恐怖直播》和《》，这10部影片中现实题材的影片占多数，而其中《熔炉》《素媛》揭露的未成年人性侵案，《辩护人》揭露的政府肆意践踏人权，《恐怖直播》中对电视台内部记者受贿说假话，主持人争权夺利，政府部门不愿意承认错误等等的讽刺，应该让很多中国人感同身受。韩国废除电影审查制度已有几十年时间，这几十年时间中诞生了多少鱼龙混在的电影，我没有做过统计，但却诞生了这么多伟大的电影，我想我可以用伟大来形容，《素媛》让韩国法律改变，《辩护人》让33年前的旧案翻盘，而《7号房的礼物》一片中的小女孩长大成为律师之后，给他的智障父亲翻案，这一系列的电影都在围绕着公平与公正展开，人类普世的价值从来不会因为外力的打击而消失，即使一时被打压，总有一天，所有尘封的黑暗历史都会展露在眼前。抛开现实题材，抛开犯罪电影，韩国的爱情片是最为人知晓的，即使是同样的剧本，韩国总能拍出不一样的味道，我并不是专业人士，也不能辨别镜头剪辑的水平，也并不能知道镜头调度的好坏，但是某种东西，某种感情，总能触动我，也似乎每部爱情片都能留下一两首脍炙人口的歌曲。

韩国电影还在发展，我期待看到更好的影片，当然我最期望能在国内影院上映一部能让我看的下去的国产良心片。

以下就是我整理的十部不得不看的韩国电影：

不得不看的电影之熔炉

韩国电影《熔炉》，视频网站都删了片源，只能下载来看。根据真实案件（性侵儿童案）改编，新闻报说促使韩国国会对相关法案进行了调整。炼心的电影。如果人都是天地培育，天生孤独，本性独立…或者更纯粹一点，存在即是不存在…会否都能活得纯粹一点… 我们一路奋战，不是为了改变世界，而是不让世界改变我们！

不得不看的韩国电影之辩护人

我们落泪，则不仅为电影，更为电影背后相似的历史与现实。我们尚且无法将历史与现实拍成电影。“他们有改变国家的电影，我们有改变电影的国家。”

2013年12月18日，《辩护人》在韩国上映。2014年2月13日，釜山地方法院对“釜林事件”二审宣判，改判被告人无罪。此刻，距离一审已经达33年之久。

不得不看的韩国电影之素媛

最孤独的人最亲切，受过伤的人总是笑的最灿烂，因为他们不愿让身边的人承受一样的痛苦

不得不看的韩国电影之7号房的礼物

当一个社会事件发生的时候，尤其当事者是弱势群体时，我们是否要跟随主流媒体去站在旁观者和道德审判者的角度去抨击当事人的无知和无耻。我们是否能独立的判断，这个事件到底是怎么样的，大多数人说的真的是事实真相吗？保持独立的观察和思考，不要成为冤假错案的帮凶，不要成为毁掉一个美好家庭的帮凶。

多年后，龙九被“洗白”，但这种翻案有没有法律效力都没有意义了，因为生命已经终结。我想起废除死刑的提议，我们是不是真的有足够正确的把握去判处一个人的死亡，而没有死亡又是否能填补被害者亲人的悲痛。

人类用千百年的时间竭力去构建一个 #理性 的审判机制，正义、自由、人权是文明社会最圣洁的象征，公检法与律师被看做是正义的代言人，但显然，现实永远不像动画片那么美好。

不得不看的韩国电影之流感

当流感来袭时，让人心寒的不是致命的病毒，而是人性的丑恶与自私。

不得不看的韩国电影之我的野蛮女友

我从来都不认为本片可以代表韩国爱情电影或者相关的电影昌盛现象！可在2002年的夏天，我和身边的一众原本对韩国电影带有蔑视态度的国内观众，却第一次真正领教了这个半岛国家在电影创作上的收放自如！我们的近邻用真正的实际行动告诉了我们，题材上的限制也可以用好的创意和想法来改变！而我们很多国人和电影制作者却仅仅看到了本片掀起的‘女强男弱’题材的热卖，造就了一票《河东狮吼》、《我的野蛮XX》系列众多东施效颦的作品。而完全没有看到韩国电影工作者的努力和想象力！ 十几年间，中国的电影票房呈现了几何程度的增长。电影市场的热卖并不是因为题材上创新能力的增强，或者观众审美水平的如何提高。仅仅是因为我们的经济水平在提高，人口基数的优势在日益显现而已！ 粗看《我的野蛮女友》不过是部有些别具一格的小清新加喜剧爱情电影，但细心看来本片却完全胜在了电影内容上的无限制性和颠覆性！它没有拘泥于某种形式上的条条框框，而是完全把富有想象力的情节段落做到了为电影本身服务，哪怕这些情节之前几乎难以被亚洲电影人所驾驭！时至今日，又有多少人曾经留意过这部电影留给过我们的感动和意外之喜。而在韩国流行文化肆虐的大陆市场，让国内众多业内人士谈‘韩’色变之时，其实邻国的文化传播及创作优势早在十几年前就已经显示出来，而我们却一直没有意识到和真正理解。。。

包裹着爱情外衣的奇幻电影

深愛自己的人，
就如電視劇裏面的男二號，
總是有的，
但懂得自己的人，
有的人一生都遇不上。

原来在这世上能遇上一个既爱你又懂得你的人是多么难得。那个爱你却不懂你的人，只能用他的爱来伤害你。你亦如此。如今，我只能眼睁睁看着这段感情在伤痕累累中慢慢消逝，无可奈何。他不懂得的，无论你怎么样解释，他还是不懂。

不得不看的韩国电影之杀人回忆

并不是每一部电影都要在最后揭晓答案，即使你百般追问、寻思闪回也不得其解。其实凶手是谁并不重要，那是一个人情味很淡的年代，各人疲于奔命只能勉强顾及自己，其实晚上戒严所有人都闭门不出是真正的凶手，军队被调去镇压游行而无法执行维护社会治安也是真正的凶手，官员的腐败导致民众的游行也是真正的凶手，所以在片尾.那个小女孩说凶手是一张很普通的脸，也就是说大部分人的冷漠杀死了受害者

不得不看的韩国电影之老男孩

你笑，世界和你一起笑；你哭，只有你一个人哭。

不得不看的韩国电影之恐怖直播

我们一路奋战，不是为了改变世界，而是不让世界改变我们！

不得不看的韩国电影之金南福杀人事件始末

最朴实的人被最信任的人唤醒心中的恶魔，才知道冷漠是这个世界上最锋利的镰刀。

还有好多好多电影值得推荐，由此可以看出韩国电影各种类型的片子百花齐放

喜剧：恋爱操作团，我的PS搭档，奇怪的她
战争：鸣梁海战，
动作：嫌疑人，
变态杀人：杀人回忆，追击者
灾难片：流感，汉江怪物
复仇：老男孩
社会边缘人物的悲剧：黄海（延边的贫民），熔炉（聋哑人），时间（整容），捉迷藏（流浪者）
友情爱情的：我脑中的橡皮擦，阳光姐妹淘，假如爱有天意，触不到的恋人，我妻子的一切，狼少年，建筑学概论
反战片：欢迎来到东莫村，

Python 方法的参数种类有很多，而不是通常语言定义的那样， Python 方法的传参能力要比想象的强大很多。很多初学者可能对一些库中带 * 带 ** 的参数类型非常奇怪，但是其实这些语法正是保证 Python 方法传参强大的重要因素。

First Thing

首先要声明 argument 和 parameter 的区别，很多时候这两个单词被直接翻译为参数更导致了很多人无法区分，argument 是调用方发起的称呼，parameter 是定义方法时使用

def foo(a, b):  # <- a and b are "parameters" or "formal arguments"
    pass

foo(1, 2)  # <- 1 and 2 are arguments to foo, that match a and b

参数类型

在讨论参数类型之前，先来看一个例子

def bar(a,    # <- this parameter is a normal python parameter
        b=1,  # <- this is a parameter with a default value
        *,    # <- all parameters after this are keyword only
        c=2,  # <- keyword only argument with default value
        d):   # <- keyword only argument without default value
    pass

这是一个典型的方法定义，其中包括了一些类型，但是还不全面。

Python 的参数类型：

• Positionals: matched from left to right 很多教程都叫做：位置参数

  顾名思义，就是从左往右匹配，比如 def foo(a, b): pass 传参的时候就必须 foo(1,'a') 按照位置传

• Keywords: matched by argument name

  也就是传参时需要指定关键词 (name=value) 这样的形式传，比如定义 def func(name=value):pass 然后调用 func(name=value)

• Defaults: specify values for arguments that aren’t passed

  可以给某些参数默认值，如果不传这些参数则使用默认值，这些可选参数传值时也需要 name=value

• Varargs collecting: collect arbitrarily many positional or keyword arguments

  方法可以使用带 * 或者 ** 的参数来收集任意长度的参数，定义方法时 def func(*name) 用来收集剩下的位置参数然后保存到 tuple 中，定义方法 def func(**name) 将收集所有的 keyword arguments 然后作为 dictionary

• Varargs unpacking: pass arbitrarily many positional or keyword arguments

  调用者可以使用 * 方式来 unpack 参数集合，比如 func(*sequence) 调用者将 sequence 的所有对象一个个按照顺序传入（作为单独的 positional arguments)， func(**dict) 调用者将 dict 中的所有 key/value 以单独的关键词参数传入 (keyword arguments)

• Keyword-only arguments: arguments that must be passed by name

  In Python 3.0 以后引入，可以指定必须 name=value 传递

总而言之，上面定义的参数类型模型，让 Python 能够决定方法需要传递多少参数，通常情况下位置参数调用者必须显示指定，而如果定义了默认参数调用者往往可以省去，而如果定义了 * 参数，则表示调用者可以传任意数量的参数。

顺序

方法定义和方法调用都要遵循一定的顺序：

• 方法调用者，参数列表需要按照如下顺序：positional arguments(value) -> keyword arguments(name=value) -> *sequence -> **dict
• 而方法定义时，参数定义需要按照： normal arguments(name)， 跟着 default arguments(name=value), -> *name -> name or name=value keyword-only arguments -> **name

在定义和调用时， **arg 如果定义都必须在最后出现，如果不按照顺序使用，会给出语法错误。 Python 内部按照下面的步骤来匹配参数列表：

• 先按照 positional arguments 来赋值，对于任何 positional arguments：

  1. 尝试将 argument 绑定到第一个没有填充的 parameter slot，如果 slot 不是 vararg slot，标记 slot 为 filled 。
  2. 如果下一个 unfilled slot 是一个 vararg slot，并且没有 name 那么报错
  3. 否则（下一个 unfilled slot 是一个 vararg slot)，所有剩下的 non-keyword arguments 都传给 vararg slot。

• 再按照 keyword arguments 来赋值任何匹配的参数

  1. 如果 parameters 中存在 name 和 keyword 匹配的参数，在将 argument value 赋值给 parameter slot. 如果 parameter slot 已经 filled，报错
  2. 否则，如果有 keyword dictionary argument, argument 就添加到存在的 dictionary，如果已经存在同名 key，则报错
  3. 否则，如果没有 keyword dictionary, 并且没有匹配的 named parameters , 报错
• 将剩余没有 keyword 的参数赋值给 *name 元组
• 将剩余的 keyword 参数赋值给 **name 字典

• 最后将默认值赋值给没有传入的参数

  • 如果 vararg slot 还没有填充，将空的 tuple 赋值给他
  • 对于剩下的空的 slot，如果有默认值则填充，如果没有默认值，则报错

在这些之后，Python 会检查每个参数都已经有且仅有一个值，如果不是将抛出错误。一旦匹配完成，Python 就将传入的对象赋值给参数名。

在这些都理清楚之后 Python 3.0 还有一个 keyword-only arguments 似乎还要费些笔墨。

Python 3.0 Keyword-Only Arguments

Python 3.0 总结了定义方法时参数列表的顺序，允许我们使用 keyword-only arguments —- 这类参数只能通过 keyword 传入，永远不会使用 positional argument 来填充。当我们既想要方法处理任意数量的 arguments 并且也可选的接受一些 configuration 选项时。

句法上， keyword-only arguments 类似于 named arguments，但是出现在 *args 后面。所有这类 argument 都必须在调用时使用 keyword 形式传入。

>>> def kwonly(a, *b, c):
        print(a, b, c)

>>> kwonly(1, 2, c=3)
1 (2,) 3

>>> kwonly(a=1, c=3)
1 () 3

>>> kwonly(1,2,3)
TypeError: kwonly() needs keyword-only argument c

这里 *b 如果不需要任意长度可以简写为 *

>>> def kwonly(a, *, b, c):
        print(a, b, c)

>>> kwonly(1, c=3, b=2)
1 2 3
>>> kwonly(c=3, b=2, a=1)
1 2 3
>>> kwonly(1,2,3)
TypeError: kwonly() takes exactly 1 positional argument (3 given)
>>> kwonly(1)
TypeError: kwonly() needs keyword-only argument b

在 * 之后依然可以使用带默认值的参数，b,c 如果被使用到则必须使用 keyword

>>> def kwonly(a, *, b='spam', c='ham'):
...
print(a, b, c)
...
>>> kwonly(1)
1 spam ham
>>> kwonly(1, c=3)
1 spam 3
>>> kwonly(a=1)
1 spam ham
>>> kwonly(c=3, b=2, a=1)
1 2 3
>>> kwonly(1, 2)
TypeError: kwonly() takes exactly 1 positional argument (2 given)

如果 keyword-only 参数没有默认值，则在调用时必须传入

在调用时，keyword-only 被传入时，必须要在 **args 之前

>>> def f(a, *b, c=6, **d): print(a, b, c, d)
>>> f(1, *(2, 3), **dict(x=4, y=5))
1 (2, 3) 6 {'y': 5, 'x': 4}

>>> f(1, *(2, 3), **dict(x=4, y=5), c=7)
SyntaxError: invalid syntax

>>> f(1, *(2, 3), c=7, **dict(x=4, y=5))
1 (2, 3) 7 {'y': 5, 'x': 4}

>>> f(1, c=7, *(2, 3), **dict(x=4, y=5))
1 (2, 3) 7 {'y': 5, 'x': 4}

>>> f(1, *(2, 3), **dict(x=4, y=5, c=7))
1 (2, 3) 7 {'y': 5, 'x': 4}

为什么要有 keyword-only arguments ，简单的来说，就是想让方法支持任意的 positional arguments 并且让 configuration 选项作为 keyword 传入。

比如想要实现一个函数，处理传入的一组对象，并且有一个开关用来指定处理完成之后是否通知

process(X, Y, Z)
process(X, Y, notify=True)

如果没有 keyword-only arguments，我们可能需要同时使用 *args 和 **args 并且人工的从 keywords 中获取 notify 。使用 keyword-only 可以节省很多

def process(*args, notify=False): ...

reference

• https://www.python.org/dev/peps/pep-3102/

Argument passing 指的是方法传参，对象是如何被传送到方法作为输入的。

下面是传参的几个要点：

• Arguments are passed by automatically assigning objects to local variable names.

  参数被传递后自动将赋值给局部变量名

• Assigning to argument names inside a function does not affect the caller

  在方法内部对参数进行赋值，不会影响调用者

• Changing a mutable object argument in a function may impact the caller

  方法可能会原地修改可变对象，从而影响到调用者

记住以上几点就能够清晰的明白 Python 中传参的要点了。Learning Python 一书中将 Python 传参模型和 C 语言比较，他们都有共同点：

• Immutable arguments are effectively passed “by value.”
• Mutable arguments are effectively passed “by pointer.”

Python 的这种传值机制使得在函数中传递对象变得非常简单，即使是很大的对象传递一个”指针“也非常快速。但是对于编程者而言需要非常明确地知道，在传递可变对象时需要特别当心方法会修改对象值。所以有必要的情况下，先拷贝一份对象内容再传递给方法。

举例

例子

def test_function_args(s: str, i: int, t: tuple, d: dict, c: tuple):
    print('-' * 10)
    print(f's id: {id(s)}, value: {s}')
    print(f'i id: {id(i)}, value {i}')
    print(f't id: {id(t)}, value {t}')
    print(f'd id: {id(d)}, value {d}')
    print(f'c id: {id(c)}, value {c}')
    print('-' * 10)
    s = 'in function'
    i = i + 10
    t = (3, 4)
    d['age'] = '20'
    c[0].append(3)
    print('-' * 10)
    print(f's id: {id(s)}, value: {s}')
    print(f'i id: {id(i)}, value {i}')
    print(f't id: {id(t)}, value {t}')
    print(f'd id: {id(d)}, value {d}')
    print(f'c id: {id(c)}, value {c}')
    print('-' * 10)


if __name__ == '__main__':
    s = 'this is a test s'
    i = 10
    t = (1, 2)
    d = {'name': 'ev'}
    c = ([1, 2], 3.14)
    print('-' * 10)
    print(f's id: {id(s)}, value: {s}')
    print(f'i id: {id(i)}, value {i}')
    print(f't id: {id(t)}, value {t}')
    print(f'd id: {id(d)}, value {d}')
    print(f'c id: {id(c)}, value {c}')
    print('-' * 10)
    test_function_args(s, i, t, d, c)
    print('-' * 10)
    print(f's id: {id(s)}, value: {s}')
    print(f'i id: {id(i)}, value {i}')
    print(f't id: {id(t)}, value {t}')
    print(f'd id: {id(d)}, value {d}')
    print(f'c id: {id(c)}, value {c}')
    print('-' * 10)

输出

----------
s id: 139714585800824, value: this is a test s
i id: 9277184, value 10
t id: 139714585799240, value (1, 2)
d id: 139714605570160, value {'name': 'ev'}
c id: 139714585797704, value ([1, 2], 3.14)
----------
----------
s id: 139714585800824, value: this is a test s
i id: 9277184, value 10
t id: 139714585799240, value (1, 2)
d id: 139714605570160, value {'name': 'ev'}
c id: 139714585797704, value ([1, 2], 3.14)
----------
----------
s id: 139714605058544, value: in function
i id: 9277504, value 20
t id: 139714585798664, value (3, 4)
d id: 139714605570160, value {'name': 'ev', 'age': '20'}
c id: 139714585797704, value ([1, 2, 3], 3.14)
----------
----------
s id: 139714585800824, value: this is a test s
i id: 9277184, value 10
t id: 139714585799240, value (1, 2)
d id: 139714605570160, value {'name': 'ev', 'age': '20'}
c id: 139714585797704, value ([1, 2, 3], 3.14)
----------

不同预设 USING THE DIFFERENT PRESETS

不同的预设命名都是不同的，开头除了N，之外还有C，F之类，上面演示中N代表的是 Nikon。其他不同字母代表意义如下：

• C - Canon
• F - Fuji
• L - Leica
• N - Nikon
• O - Olympus
• S - Standard
• SO - Sony

相同预设不同版本 FILM PRESET VERSIONS

每一种预设都包含多种版本，用来适应曝光，光照等等因素的影响。每一种胶片模拟都有一个”Normal”的版本，以他的名字命名，不包含任何符号后缀，比如”C - Kodak Portra 400”。

包含+，++，+++符号

包含+符号的版本展示更多的颗粒感，颜色更加强烈(gritter, more aggressive)。通常情况下这些版本产生更多的色调(color toning),阴影(fading),和颗粒(grain)。这些版本产生的效果通常相当于曝光不足，和(scanning variations due to non- daylight white balance conditions at the scene.)

包含-，–，—符号

带-号的预设提供Normal预设较轻柔的版本。通常情况下，这些预设调低对比度，降低颗粒感。

UC,NC,VC 含义

VSCO Film 02 中包含内容， UC 是 “Ultra Color”缩写，提供了合适的色彩饱和度（improved color saturation）和丰富的细节（details with fine grain）。 NC 是 “Natural Color”缩写，适合于低对比度环境（low contrast situation）。 VC 是 “Vivid Color”缩写，适合于中等对比度照片（medium contrast images）。

HC

HC是“High Contrast”的缩写，这些版本提供更加醒目的结果。他们达到的效果和通过工具栏的Contrast滑块调整的效果不一样。

ALT

根据官方的文档, VSCO Film 03 中因为 instant films 的效果和拍摄当时的环境相关， VSCO 为了尽量模拟当时的环境，所以每种滤镜都有不同的版本，ALT 版本就是在其他 + 或者 ++ 版本都无法表现的时候的 Alternative 版本。

VSCO FILM 01

FILM 01：现代系列(Modern Films)，收录了当下在产的专业 负片¹，是一个优秀的全能包，包括：

推荐Kodak Portra 400， Fuji 160C ，Fuji 400H（过曝情况下更合适），黑白胶片质感不强。

COLOR

• Kodak Portra 160 / Kodak Portra 160 ++ / Kodak Portra 160 + / Kodak Portra 160 -
• Kodak Portra 400 / Kodak Portra 400 ++ / Kodak Portra 400 + / Kodak Portra 400 -
• Kodak Portra 800 / Kodak Portra 800 ++ / Kodak Portra 800 + / Kodak Portra 800 -
• Kodak Portra 800 HC
• Fuji 160C / Fuji 160C ++ / Fuji 160C + / Fuji 160C -
• Fuji 400H / Fuji 400H ++ / Fuji 400H + / Fuji 400H - / Fuji 800Z
• Fuji 800Z ++ / Fuji 800Z + / Fuji 800Z -

BLACK & WHITE

• Kodak Tri-X / Kodak Tri-X ++ / Kodak Tri-X + / Kodak Tri-X -
• Kodak T-MAX 3200 / Kodak T-MAX 3200 + / Kodak T-MAX 3200 -
• Ilford HP5 / Ilford HP5 + / Ilford HP5 -

VSCO Film 01 review

VSCO FILM 02

FILM 02：经典系列(Classic Films)，收录了一些已经停产的经典 负片¹，该系列产生一种复古风格，适用于日常生活，婚礼和肖像摄影。

Fuji Superia 系列，室外阴天或者绿色较多情况适用。Kodak Portra 是 01 中Kodak老版本，建议对比使用01中的系列。

包括：

• Fuji Neopan 1600 / + / ++ / -
• Fuji Superia 100 / + / ++ / -
• Fuji Superia 400 / + / ++ / -
• Fuji Superia 800 / + / ++ / -
• Fuji Superia 1600 / + / ++ / -
• Ilford Delta 3200 / + / ++ / -
• Kodak Portra 160 NC / + / ++ / -
• Kodak Portra 160 VC / + / ++ / -
• Kodak Portra 400 NC / + / ++ / -
• Kodak Portra 400 UC / + / ++ / -
• Kodak Portra 400 VC / + / ++ / -

VSCO Film 02 walkthrough

VSCO FILM 03

FILM 03：即时显影系列(Instant films)，收录了在产及停产的 即时显影胶片² 。Film 03 pack中又包含了消费级(consumer)和专业级(professional)，即时成像的照片和周围环境温度相关，所以每一种预设又包含了很多 Cold 和 Warm 版本，适用于街景，旅游，日常生活。

包括：

• PX-70 / - / - - / + / ++ / +++ /
• PX-70 Cold / - / - - / + / ++ /
• PX-70 Warm / - / - - / + / ++ /
• PX-100UV+ Cold / - / - - / + / ++ / +++ /
• PX-100UV+ Warm / - / - - / + / ++ / +++ /
• PX-680 / - / - - / + / ++ /
• PX-680 Cold / - / - - / + / ++ / ++ Alt/
• PX-680 Warm / - / - - / + / ++ /
• Time-Zero Polaroid (Expired) / - / - - / - - - / + / ++ /
• Time-Zero Polaroid (Expired) Cold / - / - - / - - - /
• Fuji FP-100c / - / - - / + / ++ / ++ Alt / +++ /
• Fuji FP-100c Cool / - / - - / + / ++ /
• Fuji FP-100c Negative / - / - - / + / ++ / ++ Alt / +++ /
• Fuji FP-3000b / - / - - / + / ++ / +++ / HC /
• Fuji FP-3000b Negative / - / - - / + / ++ / ++ Alt /
• Polaroid 665 / - / - - / + / ++ /
• Polaroid 665 Negative / - / + / ++ / HC /
• Polaroid 669 / - / - - / + / ++ / +++ /
• Polaroid 669 Cold / - / - - / + /
• Polaroid 690 / - / - - / + / ++ /
• Polaroid 690 Warm / - / - - / + / ++ /
• Polaroid 690 Cold / - / - - / + / ++ /

VSCO Film 03 VSCO Film 03 video walkthrough

VSCO FILM 04

FILM 04：正片系列(Slide Films)，收录了在产和停产的经典 正片³ ，这组预设有高对比度，浓重的色彩，适合于旅行，风景，街道和时尚摄影，一般用来处理商业片，风光片，或者纪实片，不要用来处理人像，包括：

• Agfa Scala 200 - / – / + / -/+ / + / ++ / Contrast + / ++ / +++
• Fuji Astia 100F - / – / + / ++ / Balance Cool / Balance Warm / HC / Portrait
• Fuji Fortia SP - / – / + / ++ / +++ / Balance Cool / Balance Warm / Landscape / Portrait
• Fuji Provia 100F - / – / + / ++ / +++ / ++++ / Balance Cool / Balance Warm / HC / Portrait
• Fuji Provia 400X - / – / + / ++ / +++ / Balance Cool / Balance Warm / HC / HC + / HC ++ / Portrait / Vibrant
• Fuji Velvia 50 - / – / + / ++ / +++ / Balance Cool / Balance Warm / HC / Landscape / Landscape+
• Fuji Velvia 100 - / – / + / ++ / +++ / Balance Cool / Balance Warm / HC / Landscape
• Fuji Velvia 100F - / – / + / ++ / +++ / Balance Cool / Balance Warm / HC / Portrait
• Kodak E100G - / – / + / ++ / +++ / Balance Cool / Balance Warm (GX) / HC / Portrait / Vibrant
• Kodak E100VS - / – / + / ++ / +++ / Balance Cool / Balance Warm / Balance Warm + / Portrait
• Kodak E200 - / – / + / ++ / ++ Alt / +++ / Balance Cool / Balance Warm / HC / Portrait / Vibrant

VSCO Film 04 video walkthrough

VSCO FILM 05

FILM 05：原型系列(Archetype Films)，这个是新出的系列，收录了胶片时期市场占有率较大的几种消费级胶片。FILM 05 可以产生一种老旧胶片的美感，适合肖像，婚礼和生活场景。

Agfa Vista，表现红色，减弱青色，夕阳；Kodak Ektar，中性背景下使用；Kodak Gold， Kodak Royal Gold 适合表现黄色色调。

包括：

• Agfa Vista 100 - / – / + / ++ / +++ / Contrast + / Cool / Cool + / Portrait / Soft Highs / Vibrant / Warm / Warm +
• Agfa Vista 400 - / – / + / ++ / Contrast ++ / Cool / Cool + / Portrait / Soft Highs / Vibrant / Warm / Warm + / Night/Tungsten / Night/Tungsten + / Night/Tungsten Alt
• Agfa Vista 800 - / – / + / ++ / Contrast + / Cool / Cool + / Soft Highs / Vibrant / Warm / Warm + / Night/Tungsten / Night/Tungsten + / Night/Tungsten Alt
• Fuji Neopan 400 - / – / + / ++ / +++ / Contrast + / Contrast/Fade + / Soft Highs / Night/Tungsten / Night/Tungsten +
• Kodak BW400CN - / – / + / ++ / +++ / Contrast + / Contrast/Fade + / Soft Highs / Night/Tungsten / Night/Tungsten +
• Kodak Ektar 100 - / – / + / + Blue / + Magenta / ++ / ++ Blue / +++ / Contrast + / Cool / Cool + / Soft Highs / Vibrant / Warm / Warm - / Warm +
• Kodak Gold 100 - / – / + / + Alt / + Alt 2/ + Soft Highs / ++ / +++ / Contrast + / Cool / Cool + / Portrait / Vibrant / Warm / Warm +
• Kodak Gold 200 - / – / + / ++ / ++ Alt / +++ / Contrast + / Cool / Cool + / Green / Portrait / Soft Highs / Vibrant / Warm / Warm +
• Kodak Max 800 - / – / + / ++ / +++ / Alt / Alt + / Alt ++ / Alt Cool / Alt Warm / Contrast + / Cool / Cool + / Soft Highs / Vibrant / Warm / Warm + / Night/Tungsten / Night/Tungsten + / Night/Tungsten Alt
• Kodak Royal Gold 400 - / – / + / ++ / +++ / Contrast + / Cool / Cool + / Soft Highs / Vibrant / Warm / Warm + / Night/Tungsten / Night/Tungsten + / Night/Tungsten Alt
• Kodak Ultramax 400 - / – / + / + Green / ++ / ++ Green / +++ / Contrast + / Cool / Cool + / Soft Highs / Vibrant / Warm / Warm + / Night/Tungsten / Night/Tungsten + / Nigh/Tungsten Alt
• Kodak Ultramax 800 - / – / + / + Alt / ++ / +++ / Contrast + / Cool / Cool + / Soft Highs / Vibrant / Warm / Warm + / Night/Tungsten / Night/Tungsten + / Night/Tungsten Alt

Introducing VSCO Film 05 video walkthrough

VSCO Film 06

Film 06: Alternative Process Films is a well-balanced pack that includes a wide range of push and pull processed looks, which alter grain, contrast, and richness. It also includes cross processed looks, which are best suited for dramatic color effects and vibrancy. From subtle enhancements to bold stylistic editing, this collection is ideal for outdoor and lifestyle photography, modern portraiture, and sunwashed settings.

该系列预设适合拍摄婚礼，生活场景，肖像，或者阳光下场景。推荐Kodak Portra 160+1，Fuji Provia 400X XP。

• Fuji 400H+1 - / + / ++ / +++ / Night / Over / Over+ / Vibrant
• Kodak E100VS XP - / + / ++ / Green / Over
• Ilford HP5-1 - / + / ++
• Ilford HP5+1 - / + / ++
• Ilford HP5+2 - / + / ++
• Ilford HP5+3 - / + / ++
• Kodak Portra 160+1 - / + / ++ / +++ / Alt / Alt+ / Over / Vibrant
• Kodak Portra 400+1 - / + / ++ / +++ / Night / Night+ / Over / Vibrant
• Kodak Portra 400+2 - / + / ++ / Night
• Kodak Portra 400+3 - / + / ++ / Night / Night+
• Kodak Portra 800+1 - / + / ++ / ++ Green / +++ / Night / Night + / Night ++ / Over / Vibrant
• Agfa Precisa XP - / + / ++ / Green / Green- / Over
• Fuji Provia 400X XP - / + Blue / + / ++ / +++ / Over + / Over
• Fuji Provia 400X+1 - / + / ++ / +++ / Night / Night+ / Over / Over+ / Vibrant
• Fuji Sensia XP - / + / ++ / Over / Warm / Warm+ / Warm++
• Kodak TRI-X-1 - / + / ++
• Kodak TRI-X+1 - / + / ++
• Kodak TRI-X+2 - / + / ++
• Kodak TRI-X+3 - / + / ++

VSCO Film 07

Film 07: Eclectic Films features a wide range of looks in our largest release to date, with 18 films and over 100 presets in total. The spectrum of this collection translates to versatility in use and includes muted, vivid, tungsten-balanced, and black and white films — all of which embody an elegant and modern aesthetic. This pack is ideal for most settings and subjects, particularly portraits, night photography, and architecture.

该系列预设适合特定场景的肖像，夜景。推荐Fuji 160S 和 Agfa Ultra 系列。

• Agfa Optima 100 II – / - / + / ++ / Cool / Warm
• Agfa Portrait XPS 160 – / - / + / ++ / Cool / Warm
• Agfa RSX 50 II – / - / + / ++ / Cool / Warm
• Agfa RSX 200 II – / - / + / ++ / Cool / Warm / Warm +
• Agfa Ultra 50 – / - / + / ++ / Cool / Warm
• Agfa Ultra 100 – / - / + / ++ / Cool / Warm
• Fuji 160S – / - / + / ++ / Alt / Cool / Warm
• Fuji Sensia 100 – / - / + / ++ / Alt / Cool / Warm
• Ilford Pan F Plus 50 – / - / + / ++
• Kodak Ektachrome 64 – / - / + / ++ / Alt / Cool / Warm
• Kodak Ektar 25 – / - / + / ++ / Cool / Warm
• Kodak Elite 50 II – / - / + / ++ / Cool / Warm
• Kodak Plus-X 125 – / - / + / ++
• Kodak Tri-X 320 – / - / + / ++ / +++
• Fuji T64 – / - / + Alt / + / ++
• Kodak Ektachrome 64T – / - / + / ++
• Kodak Elite Chrome 160T – / - / + / ++ / Alt + / Alt / Cool / Warm
• Kodak Portra 100T – / - / + / ++ / Cool / Warm

vsco film 07 review

Reference

VSCO Cam 一直深受摄影爱好者的喜爱，VSCO Cam 能够提供极佳的模拟胶片效果(analog film)。而桌面的 VSCO 产品叫做 VSCO Film，这些天试用 Adobe Light Room 突然想起来这样一款产品，上官网一查，VSCO Film 给入门者提供了一套免费的预设(Preset)—-VSCO FILM 00 free starter pack，正好试用一下。

VSCO FILM 00 free starter pack

• 官网及下载地址：http://vsco.co/film/00/lightroom
• 产品介绍及效果演示：http://grid.vsco.co/journal/introducing-vsco-film-00-free-starter-pack

VSCO Film 00 is a FREE starter pack which includes two of our most popular digital emulations of analog film (Kodak Gold 100 from Film 05 and Kodak Tri-X from Film 06).

Perfect for anyone who uses VSCO Cam and is looking to take the next step, VSCO Film 00 brings beautiful presets, custom camera profiles, and the familiar VSCO editing experience to your desktop in Adobe Lightroom (available for a free trial here).

预设安装的路径： C:\Users\Ein Verne\AppData\Roaming\Adobe\Lightroom

预设效果演示(官方演示请见以上链接)：

原图

N-Kodak Gold 100

N-Kodak Gold 100 Warm

N-TRI-X+1

最近整理轻单的内容，发现了之前整理过的一些关于轻单的想法，现在就当是备份吧。原单内容部分由复制他人轻单内容而来。轻单早期是有类似Github fork的复制轻单功能的，后来去掉了。

##够“轻”，但不够简“单”

轻，是我知道可以看什么，不够简“单”，是我不知道该发布什么。知乎/Quora以问题为切入口，引导UGC；豆瓣以图片/电影等内容评论为切入口，来引导；Pinterest以图片收集为切入口，来引导收集整理； 轻单，只提供了新的类容发布形式，却没有给出好的内容发布引导。大类别分类，贪大求全，定位不明，其实也是形式创新局限的表现。 “显性内容决定产品气质”，目测又是一个互联网蝗虫的小圈子玩物 （虽然有问题，但写List确实是喜闻乐见的形式）

From:qdan

##列表形式 在早期使用轻单的时候就是不知道写什么内容，对于列表这样的一个形式无意中对内容有了较大的限制。而反过来列表的形式又给予了内容更多的整理。轻单内容用来做分享，用来整理个人知识是很好的，当你真正理解这样的一个形式之后，对自己还是他人都是很有帮助的，就像我一直订阅的台湾一位作者的博客—-电脑玩物，其实说白了，作者很大一部分内容都是整理列表—-旅行你需要的App，10大素材网站等等。只是作者通过博客，以列表的形式分享了出来。而我们平时如果学会了这样的一种方法，对个人知识的整理是大有益处的。比如我自己学习Vim，Git在初期看了很多的资料，有段时间会很混乱，而如果一段时间之后整理自己学到的知识，并且用列表的形式分享出来会得到更好的理解。 就像上面提到的一样，轻单没有引导UGC，因此新用户会完全找不到主题，或者内容。而我之前也发过一个轻单说“豆瓣无所不在的豆列对轻单是不是一种威胁”，里面提到我会用豆瓣列表去整理看过的电影，会用网易云音乐去整理喜欢的歌曲，而订阅源的列表分享我会用InoReader集成的功能。定期的整理对自己知识体系的形成会有很大的帮助。而如果想要与别人分享，轻单，我说列表，这样的形式对读者有很大的帮助。 回想起来豆瓣在全站推广豆列，Google+更新Collection功能，是不是对列表这种形式的认可呢？

##复制列表 由上，引出了轻单早期的“复制轻单”功能，我一直认为这样的一个功能是Github fork的延伸，我觉得我可以使用复制轻单这样的功能给原始轻单添加更多内容，并且分享出来。而现实中“复制轻单”这个功能并没有很多的人使用，所以后来这个功能也就消失了。

##总结 轻单的创业已经告一段落，开发团队也已经解散了。对于我这样的用户来说，改变并不是很大，我依然用着List这样的形式来写下这样一篇总结，我依然还是用着很多的List来整理方方面面。但是对于一个产品来说，轻单算是一个终结了，期待有更多的新想法的产生，并由此诞生出伟大的产品。

曾经收藏过的一篇文章 How to write a Git commit message，今天无意中点开却发现网站无法访问，故而使用 Google Cache 恢复该文。后来发现作者网站虽然无法访问，但是作者将网站开源 了。

Introduction: Why good commit messages matter

If you browse the log of any random git repository you will probably find its commit messages are more or less a mess. For example, take a look at these gems from my early days committing to Spring:

$ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009"

e5f4b49 Re-adding ConfigurationPostProcessorTests after its brief removal in r814. @Ignore-ing the testCglibClassesAreLoadedJustInTimeForEnhancement() method as it turns out this was one of the culprits in the recent build breakage. The classloader hacking causes subtle downstream effects, breaking unrelated tests. The test method is still useful, but should only be run on a manual basis to ensure CGLIB is not prematurely classloaded, and should not be run as part of the automated build.
2db0f12 fixed two build-breaking issues: + reverted ClassMetadataReadingVisitor to revision 794 + eliminated ConfigurationPostProcessorTests until further investigation determines why it causes downstream tests to fail (such as the seemingly unrelated ClassPathXmlApplicationContextTests)
147709f Tweaks to package-info.java files
22b25e0 Consolidated Util and MutableAnnotationUtils classes into existing AsmUtils
7f96f57 polishing

Yikes. Compare that with these more recent commits from the same repository:

$ git log --oneline -5 --author pwebb --before "Sat Aug 30 2014"

5ba3db6 Fix failing CompositePropertySourceTests
84564a0 Rework @PropertySource early parsing logic
e142fd1 Add tests for ImportSelector meta-data
887815f Update docbook dependency and generate epub
ac8326d Polish mockito usage

Which would you rather read?

The former varies wildly in length and form; the latter is concise and consistent. The former is what happens by default; the latter never happens by accident.

While many repositories’ logs look like the former, there are exceptions. The Linux kernel and git itself are great examples. Look at Spring Boot, or any repository managed by Tim Pope.

The contributors to these repositories know that a well-crafted git commit message is the best way to communicate context about a change to fellow developers (and indeed to their future selves). A diff will tell you what changed, but only the commit message can properly tell you why. Peter Hutterer makes this point well:

Re-establishing the context of a piece of code is wasteful. We can’t avoid it completely, so our efforts should go to reducing it [as much] as possible. Commit messages can do exactly that and as a result, a commit message shows whether a developer is a good collaborator.

If you haven’t given much thought to what makes a great git commit message, it may be the case that you haven’t spent much time using git log and related tools. There is a vicious cycle here: because the commit history is unstructured and inconsistent, one doesn’t spend much time using or taking care of it. And because it doesn’t get used or taken care of it, it remains unstructured and inconsistent.

But a well-cared for log is a beautiful and useful thing. git blame, revert, rebase, log, shortlog and other subcommands come to life. Reviewing others’ commits and pull requests becomes something worth doing, and suddenly can be done independently. Understanding why something happpened months or years ago becomes not only possible but efficient.

A project’s long-term success rests (among other things) on its maintainability, and a maintainer has few tools more powerful than his project’s log. It’s worth taking the time to learn how to care for one properly. What may be a hassle at first soon becomes habit, and eventually a source of pride and productivity for all involved.

In this post, I am addressing just the most basic element of keeping a healthy commit history: how to write an individual commit message. There are other important practices like commit squashing that I am not addressing here. Perhaps I’ll do that in a subsequent post.

Most programming languages have well-established conventions as to what constitutes idiomatic style, i.e. naming and formatting and so on. There are variations on these conventions, of course, but most developers agree that picking one and sticking to it is far better than the chaos that ensues when everybody does their own thing.

A team’s approach to its commit log should be no different. In order to create a useful revision history, teams should first agree on a commit message convention that defines at least the following three things:

Style. Markup syntax, wrap margins, grammar, capitalization, punctuation. Spell these things out, remove the guesswork, and make it all as simple as possible. The end result will be a remarkably consistent log that’s not only a pleasure to read but that actually does get read on a regular basis.

Content. What kind of information should the body of the commit message (if any) contain? What should it not contain?

Metadata. How should issue tracking IDs, pull request numbers, etc. be referenced?

Fortunately, there are well-established conventions as to what makes an idiomatic git commit message. Indeed, many of them are assumed in the way certain git commands function. There’s nothing you need to re-invent. Just follow the seven rules below and you’re on your way to committing like a pro.

The seven rules of a great git commit message

Keep in mind: This has all been said before.

1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how

For example:

Summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.

Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequenses of this
change? Here's the place to explain them.

Further paragraphs come after blank lines.

 - Bullet points are okay, too

 - Typically a hyphen or asterisk is used for the bullet, preceded
   by a single space, with blank lines in between, but conventions
   vary here

If you use an issue tracker, put references to them at the bottom,
like this:

Resolves: #123
See also: #456, #789

1. Separate subject from body with a blank line

From the git commit manpage:

Though not required, it’s a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. The text up to the first blank line in a commit message is treated as the commit title, and that title is used throughout Git. For example, git-format-patch(1) turns a commit into email, and it uses the title on the Subject line and the rest of the commit in the body.

Firstly, not every commit requires both a subject and a body. Sometimes a single line is fine, especially when the change is so simple that no further context is necessary. For example:

Fix typo in introduction to user guide

Nothing more need be said; if the reader wonders what the typo was, she can simply take a look at the change itself, i.e. use git show or git diff or git log -p.

If you’re committing something like this at the command line, it’s easy to use the -m switch to git commit:

$ git commit -m "Fix typo in introduction to user guide"

However, when a commit merits a bit of explanation and context, you need to write a body. For example:

Derezz the master control program

MCP turned out to be evil and had become intent on world domination.
This commit throws Tron's disc into MCP (causing its deresolution)
and turns it back into a chess game.

This is not so easy to commit this with the -m switch. You really need a proper editor. If you do not already have an editor set up for use with git at the command line, read this section of Pro Git.

In any case, the separation of subject from body pays off when browsing the log. Here’s the full log entry:

$ git log
commit 42e769bdf4894310333942ffc5a15151222a87be
Author: Kevin Flynn <kevin@flynnsarcade.com>
Date:   Fri Jan 01 00:00:00 1982 -0200

 Derezz the master control program

 MCP turned out to be evil and had become intent on world domination.
 This commit throws Tron's disc into MCP (causing its deresolution)
 and turns it back into a chess game.

And now git log --oneline, which prints out just the subject line:

$ git log --oneline
42e769 Derezz the master control program

Or, git shortlog, which groups commits by user, again showing just the subject line for concision:

$ git shortlog
Kevin Flynn (1):
      Derezz the master control program

Alan Bradley (1):
      Introduce security program "Tron"

Ed Dillinger (3):
      Rename chess program to "MCP"
      Modify chess program
      Upgrade chess program

Walter Gibbs (1):
      Introduce protoype chess program

There are a number of other contexts in git where the distinction between subject line and body kicks in—but none of them work properly without the blank line in between.

2. Limit the subject line to 50 characters

50 characters is not a hard limit, just a rule of thumb. Keeping subject lines at this length ensures that they are readable, and forces the author to think for a moment about the most concise way to explain what’s going on.

Tip: If you’re having a hard time summarizing, you might be committing too many changes at once. Strive for _atomic commits_ (a topic for a separate post).

GitHub’s UI is fully aware of these conventions. It will warn you if you go past the 50 character limit:

And will truncate any subject line longer than 69 characters with an ellipsis:

So shoot for 50 characters, but consider 69 the hard limit.

3. Capitalize the subject line

This is as simple as it sounds. Begin all subject lines with a capital letter.

For example:

• Accelerate to 88 miles per hour

Instead of:

• accelerate to 88 miles per hour

4. Do not end the subject line with a period

Trailing punctuation is unnecessary in subject lines. Besides, space is precious when you’re trying to keep them to 50 chars or less.

Example:

• Open the pod bay doors

Instead of:

• Open the pod bay doors.

5. Use the imperative mood in the subject line

Imperative mood just means “spoken or written as if giving a command or instruction”. A few examples:

• Clean your room
• Close the door
• Take out the trash

Each of the seven rules you’re reading about right now are written in the imperative (“Wrap the body at 72 characters”, etc).

The imperative can sound a little rude; that’s why we don’t often use it. But it’s perfect for git commit subject lines. One reason for this is that git itself uses the imperative whenever it creates a commit on your behalf.

For example, the default message created when using git merge reads:

Merge branch 'myfeature'

And when using git revert:

Revert "Add the thing with the stuff"

This reverts commit cc87791524aedd593cff5a74532befe7ab69ce9d.

Or when clicking the “Merge” button on a GitHub pull request:

Merge pull request #123 from someuser/somebranch

So when you write your commit messages in the imperative, you’re following git’s own built-in conventions. For example:

Writing this way can be a little awkward at first. We’re more used to speaking in the indicative mood, which is all about reporting facts. That’s why commit messages often end up reading like this:

And sometimes commit messages get written as a description of their contents:

To remove any confusion, here’s a simple rule to get it right every time.

A properly formed git commit subject line should always be able to complete the following sentence:

• If applied, this commit will your subject line here

For example:

• If applied, this commit will _refactor subsystem X for readability_
• If applied, this commit will _update getting started documentation_
• If applied, this commit will _remove deprecated methods_
• If applied, this commit will _release version 1.0.0_
• If applied, this commit will _merge pull request #123 from user/branch_

Notice how this doesn’t work for the other non-imperative forms:

• If applied, this commit will _fixed bug with Y_
• If applied, this commit will _changing behavior of X_
• If applied, this commit will _more fixes for broken stuff_
• If applied, this commit will _sweet new API methods_

Remember: Use of the imperative is important only in the subject line. You can relax this restriction when you’re writing the body.

6. Wrap the body at 72 characters

Git never wraps text automatically. When you write the body of a commit message, you must mind its right margin, and wrap text manually.

The recommendation is to do this at 72 characters, so that git has plenty of room to indent text while still keeping everything under 80 characters overall.

A good text editor can help here. It’s easy to configure Vim, for example, to wrap text at 72 characters when you’re writing a git commit. Traditionally, however, IDEs have been terrible at providing smart support for text wrapping in commit messages (although in recent versions, IntelliJ IDEA has finally gotten better about this).

7. Use the body to explain what and why vs. how

This commit from Bitcoin Core is a great example of explaining what changed and why:

commit eb0b56b19017ab5c16c745e6da39c53126924ed6
Author: Pieter Wuille <pieter.wuille@gmail.com>
Date:   Fri Aug 1 22:57:55 2014 +0200

   Simplify serialize.h's exception handling

   Remove the 'state' and 'exceptmask' from serialize.h's stream
   implementations, as well as related methods.

   As exceptmask always included 'failbit', and setstate was always
   called with bits = failbit, all it did was immediately raise an
   exception. Get rid of those variables, and replace the setstate
   with direct exception throwing (which also removes some dead
   code).

   As a result, good() is never reached after a failure (there are
   only 2 calls, one of which is in tests), and can just be replaced
   by !eof().

   fail(), clear(n) and exceptions() are just never called. Delete
   them.

Take a look at the full diff and just think how much time the author is saving fellow and future committers by taking the time to provide this context here and now. If he didn’t, it would probably be lost forever.

In most cases, you can leave out details about how a change has been made. Code is generally self-explanatory in this regard (and if the code is so complex that it needs to be explained in prose, that’s what source comments are for). Just focus on making clear the reasons you made the change in the first place—the way things worked before the change (and what was wrong with that), the way they work now, and why you decided to solve it the way you did.

The future maintainer that thanks you may be yourself!

Tips

Learn to love the command line. Leave the IDE behind.

For as many reasons as there are git subcommands, it’s wise to embrace the command line. Git is insanely powerful; IDEs are too, but each in different ways. I use an IDE every day (IntelliJ IDEA) and have used others extensively (Eclipse), but I have never seen IDE integration for git that could begin to match the ease and power of the command line (once you know it).

Certain git-related IDE functions are invaluable, like calling git rm when you delete a file, and doing the right stuff with git when you rename one. Where everything falls apart is when you start trying to commit, merge, rebase, or do sophisticated history analysis through the IDE.

When it comes to wielding the full power of git, it’s command-line all the way.

Remember that whether you use Bash or Z shell, there are tab completion scripts that take much of the pain out of remembering the subcommands and switches.

Read Pro Git

The Pro Git book is available online for free, and it’s fantastic. Take advantage!