个人关于命令行工具用户界面设计的愚见

摘要：嵌入式软件的界面设计，嵌入式软件生产过程所用工具的界面设计，其实不仅仅局限于嵌入式软件领域，因为这也是借鉴其他领域的，其他领域也可以再借鉴回去嘛。声明一点，LZ不是做界面设计的，LZ参与开发的嵌入式软件更是没有GUI界面的，所以想看的留下，不想看的刚快另寻佳文。

比如智能手机APP用户设计可以转而浏览 移动界面隐喻设计 http://9.douban.com/site/entry/180547542/view

1 没有GUI用户界面的软件是不是就是没有界面？

“用户界面”是由两个词“用户”和“界面”两个词组成的，所以首先搞清楚“用户”是谁，然后再提供给他什么“界面”。LZ参与开发的软件对最终用户虽然是没有GUI 界面，但是也有不少其他界面啊，比如要提供运行告警，要提供一些维护指令（最终用户虽然不用但我们的维护人员需要啊），所以这里你就看出来，针对不同的用户，界面的概念都是不一样的。所以谈到用户界面，不要一下子就想到搞的那个GUI怎么样啊，首先要看这个环境的用户是谁。

平时我们都是针对最终用户谈用户界面的，其实你还有其他界面，比如为了调试和测试提供的界面，也不一定是GUI界面，可能是命令行参数，还有程序运行过程信息，最终用户不会看，但是开发调试要看的。所以你的软件肯定也是针对不用的用户，不同的目的，设计进了不同的interface吧

2 纯命令行操作的软件的参数设计

先来看两个较为反面的例子。

例1，别人写的工具，用来把几个文件合并成一个文件用的，该软件要求（1）命令行参数中指明需要合并的文件的文件名，要求（2）将指定用途的文件命名成固定的文件名才能正确将它们合并。就是说既要我通过参数输入进去，还要求预先把它们命名成指定名称呢，刚开始我还不知道有（2），合并出来的文件不对，后询问工具维护者才得知还有要求（2）。

例2，不知道哪位大侠写的工具，反正公司很多项目在用，用了很久了。输入参数也是一个文件，要求是<文件名>，开始一直用着也没啥，自己还另外开发了一套更便捷的AutoIt脚本来执行这个工具，挺爽的。前不久，新项目换了平台，我还想使用原来那套自己开发的脚本，需要替换原来那个工具，那就自己搞一个吧，输入参数完全一样，用熟悉的autoit来搞，结果autoit没法接收<>包含起来的参数，它可能见到<就以为我要用指定文件的内容做输入吧，没办法，模拟不了原来那个工具，只好修改那套Autoit脚本在调用两个不同的工具时输入不同的参数。这还不是最坑爹的，部分同事新领的电脑系统成WIN7啦，原来那个工具在WIN7下不能用，怎么兼容运行也不行。

看了两个不太好的例子，那好的设计应该是什么呢？好的啊，这个，你就看操作系统提供的那些命令就可以啦，windows的linux的都可以，看那些最常用的程序的参数格式是什么，直接抄袭借鉴这些广为人知的命令是最好的办法，千万不要特立独行设计出违反常识的格式，比如你要那个方括号把文件名括起来有啥好处么？

命令行参数应该怎么设计，请阅读《Command-line interface - Wikipedia, the free encyclopedia http://en.wikipedia.org/wiki/Command-line_interface》

维基中文不给力，搜索了半天，中文找到这么一篇 《linux命令行参数处理 - 联城技术网 http://tech.16c.cn/linux/accidence/20100603/35074.html》

3 命令行界面(CLI)和图形化用户界面(GUI)

同一个工具，只提供CLI或只提供GUI可以么？

windows下自带的ping程序只有CLI吧，现在的linux发行版则都在CLI的ping之外还安装了图形化用户界面的网络工具。

对于有自动执行要求的应用来说，当然不能只提供GUI界面，所以面向开发人员使用的工具，不怕CLI，对他们来说有时CLI反而是优势。所以，你的程序怎么设计知道了吧。

很多linux下的应用都是命令行的后端程序，还有另外的项目在此之上提供GUI前端。可以照搬一下。