GUI,CLI与Unix哲学

Unix哲学提倡组合多个只做一件事的小程序。这有什么好处呢？

独立的高内聚程序可耦合成更多的可能性，只通过输入和输出耦合便是最低耦合，这话是Unix/Linux哲学的基底。

无论是GUI还是多参数CLI，均不便于多程序协作。UI是给人用的而不是给程序用的。

不妨先比较一下GUI和多参数CLI。

GUI的操作界面是二维的屏幕控件，人眼很容易识别控件，并知道该控件的用途，比方说一个写着“确定”或者“取消”的按钮，或者“视图”菜单下的“放大”。

若要GUI程序相互协作，那么程序不但要能理解控件描述并找到它的位置，还要理解控件的分类，无论是按钮，还是菜单，所有GUI控件都必须在两个维度定位，对程序而言理解这种定位是不可能的。即便对人也很难，我刚帮女儿整理了一篇Word稿子，很难找到如何调整页边距。难归难，但只要花时间，总可以“找到”控件，因为自描述的GUI控件“就在某处”。

控件定位问题在CLI上就好很多，CLI命令行就一行，一行就是一维，一维命令行无需定位，append追加参数即可，但参数以及参数的作用必须事先知道，如果事先不知道参数的含义，你永远不可能“找到”它，CLI参数并不自描述，在你append它之前，它不在任何地方。这意味着对于CLI，help或manual非常重要，没有help或manual，CLI就无法使用。

GUI自描述，通过在二维屏幕上查找定位到要操作的控件。用得不熟练的人也可以通过自描述找到控件并操作，用得熟练的人依然省不掉二维定位操作，批处理，快捷键也快不到哪去。

CLI非自描述，一维命令行无需定位，append参数即可。第一次使用必须查help或manual，否则无法使用，一旦熟练便可脚本化，相比GUI操作会非常快。

以上就是GUI和CLI的相异。但无论GUI还是CLI，指望程序之间互相理解都很困难。对于GUI，鼠标精灵之类的把戏从来就没有流行过，而对于CLI，写一个程序接收另一个程序所有输出并理解其不同含义，将使事情变得极端复杂。

唯一可以让程序之间用简易的方式协作的就是保持每一个程序单独的输入和单独的输出。
比如：

cat /opt/abc |grep '\<[0-9][0-9][0-9]\>'|uniq|sort 

虽然iptables可以很方便地阻止一个来自恶意IP的数据包，但前提是需要人来敲出整条命令，很难有一个程序可以同时输出IP地址，协议端口等match，如果分别由多个程序输出这些参数，程序之间便很难衔接，根本原因只有一个，iptables需要多个携带含义的参数。

人是智能生物，采用二分组合做事非常低效，人可以用眼识别GUI控件并操作它，人也可以理解CLI参数并append它，但程序不行，程序既找不到GUI控件并理解它，也理解不了CLI参数。如果世界上只有程序，那么最傻最合理的程序只能收敛成只做一件事，携带着做该件事明确的输入和输出，就成了这个程序的“核”，这就是Unix哲学，Unix为程序之间的协作而生。

又思考了一下GUI和CLI，觉得挺有意思的，也睡不着觉，写篇作文吧。

浙江温州皮鞋湿，下雨进水不会胖。