尽管8年后的1973年出现了图形界面程序，
16年后的1981年出现了图形界面的操作系统，
但是在此之后，至今三十几年过去了，图形界面(GUI)仍无法取代命令行界面(CLI)。命令行界面是否过时
答案是：不会的！
1965年OS/360的发布标志着与硬件分离的“通用”操作系统的出现。
尽管8年后的1973年出现了图形界面程序，
16年后的1981年出现了图形界面的操作系统，
但是在此之后，至今三十几年过去了，图形界面(GUI)仍无法取代命令行界面(CLI)。
有什么理由可以说，图形界面终将取代命令行界面呢？
不管是传统的linux“神器”，如find, grep, curl, netcat, xargs, rsync,
screen，awk, vi, emacs， 还是让人惊叹的新作，如maven, git,
salt，都有着强大的命令行界面。甚至你会有一种感觉：
为这些软件设计图形界面根本就是画蛇添足。
命令行界面的优势在于：
- 效率高
鼠标操作是最简单，同时也是最笨拙的操作
- 更专注
鼠标操作容易分心
- 速度快
CLI程序需要的资源少，启动和执行速度更快
- 易远程
ssh、telnet的连接比vnc、remote desktop等更容易
- 自动化
CLI不仅可以给人使用，也适用于自动化脚本
- zhuangbility
^o^
命令行界面的类型
按照复杂程度，命令行界面可以分为：
- 非交互式
一次性输入所有的参数，程序执行期间不需要用户的干预。这是最常见的命令行界面形式。
- 基于行的交互
在执行过程中，需要用户输入一些内容，比如确认信息、路径参数等。
由于用户交互会使程序难以用于自动化脚本，所以这种命令行界面并不多见，常用于基于命令行的安装程序。
- 文本用户界面(TUI)
类似于图形用户界面，没有明确的执行流程，完全由用户控制程序的执行步骤。比如vi和emacs。
CLI世界的潜规则
为了使你的CLI程序不会显得格格不入，在设计CLI程序时要遵守一些潜规则。
良好命名
容易理解
名字要短
容易记忆
必备选项
所有的命令行工具都应该提供=-v/–version=和=-h/–help=选项。
- 保持安静
程序的输出要”恰到好处”，让用户/其他程序明确知道必要的信息，又不过分“啰嗦”。过多的输出即会浪费系统资源和带宽，也会让用户感觉不舒服，更重要的是会使得其他程序的处理逻辑变得复杂。以下的原则有利于保持安静：
不要输出无关的信息，比如版本号、作者名——除非用户要求
对于很明确的结果，不需要再提醒用户。只应提示例外(exception)情况
不需要告诉用户输出的是什么东西——用户会知道的
如有必要，可以提供=-v/–verbose=和=-q/–quiet=选项，供用户选择
明确要求
在基于行的交互式CLI中，需要用户输入时要给出明确的提示，比如：
=Do you really want to do this (y/n)?=
=Enter a date (YYYY-MM-DD):=
- 支持管道
程序应该支持从管道或文件重定向中读取数据：
如果文件名作为参数传递给程序，就读取文件的内容作为输入
如果没有提供这样的参数，就从标准输入中读取，一直到 CTRL+D
功能单一
UNIX哲学中重要的一条原则就是：每个程序只做一件事情，并把它做好。
复杂的功能通过程序间的配合完成，而为了与其他的程序配合，要尽量支持管道和重定向。
既然“只做一件事”，就要“做好一件事”。
- 遵循惯例
UNIX中命令行参数会有一些惯例，比如=-=后面的单字母选项可以连用（如=ls -Al=),
=–=后面使用多字母选项等；此外，遵循已经被广泛使用的命令的参数，也会容易被接受。
CLI支持库
CLI是如此重要，以至于很多语言/平台都提供了开发CLI的支持库，比如：
python的optparse和argparse
argparse更先进，旨在替代optparse，但是从python2.7开始才支持。如果希望在比较旧的linux上运行(通常支持python2.4)，最好还是使用optparse。
java的Apache Commons CLI
Apache karaf的karaf-command-archetype