作为一个命令行爱好者，当我看到 Klaatu 在即将到来的 All Things Open 会议日程上的演讲 Unix Shell 人机界面指南 (HIG) 时，我非常感兴趣。
虽然我一直被 Unix/Linux Shell 简洁优美的特性所吸引——是的，真的——但能与同样欣赏它的人交流总是令人愉快的。然而，Klaatu 更进一步，他定义了一些促成 Shell 优雅特性的属性。
在这次访谈中，他向我们简要介绍了他在 ATO 会议上的演讲，我计划亲自去听听他对这个话题的看法。互联网上关于 HIG 的资料很少，所以我请 Klaatu 告诉我们 HIG 的含义以及它如何影响 Linux Shell 的用户界面。当然，Klaatu 也会告诉我们他的名字的由来。
我不得不代表我自己以及许多其他人问，你的名字 Klaatu 是不是向我最喜欢的电影之一《地球停转之日》致敬？ 你是否愿意详细说明一下？
这是一个双重致敬！首先，致敬（原版，而不是翻拍版）《地球停转之日》，也致敬《鬼玩人3：魔界英豪》。前者是一部各方面都很出色的电影，但我认为它最大的力量在于它如何利用预期和电影手法来传达与各个元素所代表的意义完全相反的信息。为了避免剧透，我将避免过于具体。后者当然是一部伟大的电影，尤其是它深入分析了分叉和分支如何影响软件项目。
当我最初接触 Unix 和开源时，我正在为我做的一个名为 GNU World Order 的小播客选择笔名。我天真地认为，在一个重视技术，并且经常关注推测小说的社区中，“Klaatu”这个名字是对我最喜欢的电影的古雅而晦涩的致敬。当然，后来我了解到，在科技界，“Klaatu”作为你的网名，就像现实世界中的“Bob Smith”一样普遍，所以在线上我也被称为“notKlaatu”，以区别于其他 Klaatu。
你是如何开始接触 Unix 的？
嗯，我从来都不是 Windows 用户。我一生中在 Windows 上花费的总时间可能只有 15 分钟，甚至更少。我是在另一个商业操作系统 (OS) 上长大的。从那个系统跳到真正的 Unix 并没有那么困难。
话虽如此，我最初并没有打算从事计算机行业，而是想拍电影。我私底下其实挺 Geek 的，但我去电影学院学习电影制作。
有一天，在我去电影学院的路上，我在一本行业杂志上读到一篇文章，文章中说视觉特效公司使用 Unix，并且说他们有一种神秘的能力，可以在不启动界面的情况下启动程序。从那一刻起，我非常好奇地想知道，我如何才能在不麻烦于实际 UI 的情况下使用应用程序。
当我了解到我从小长大的操作系统“基于 Unix”时，我买了一本关于如何学习 Unix 的书（具体来说是 Unix Visual QuickStart Guide）。我开始将书中的所有内容应用到我在那个操作系统中找到的终端上。在 Emacs 的文档中（当时我主要将它用作俄罗斯方块引擎），我了解了开源和 GPL 的概念。最终，我厌倦了不断的编译器错误以及无法在不需要时避免启动桌面，所以我转而使用 Slackware Linux，并且再也没有回头。
顺便说一句，我现在从事视觉特效工作。
Unix Shell 最吸引你的是什么？
效率。我似乎对任何阻碍我实现既定目标的东西都缺乏耐心，而 Shell 是所有计算领域中唯一能让我完全按照我的意愿行事的东西。
其次是创建我自己的工作环境的能力。这花了一些时间，但一旦我学会了脚本编写的基础知识，编写自定义命令和脚本的能力就彻底改变了我的生活。
喜欢 Shell 的理由还有很多，但就目前而言，这两点最能引起我的共鸣。
HIG 代表什么？
“HIG”是我从 GNOME 那里学到的一个术语。它代表“人机界面指南”，是一套规范，用于指导开发人员如何向人们呈现应用程序的功能。
你是如何对人机界面指南产生兴趣的？
广义上讲，我认为我对这个话题并没有太大的兴趣，至少不像 UI 设计师那样。但是所有计算机用户都对人机界面指南有点兴趣，因为这是我们使用计算设备的方式。对我来说，这只是一个关于我们应该如何在一定程度上达成共识，即计算机应该如何工作的问题。这是我们努力在应用程序的使用方式上形成共同趋势的努力。
我不知道汽车制造商是如何做到的，但一般来说，如果你进入一辆汽车，即使是新西兰的汽车（驾驶座在左边），你基本上也知道所有东西的位置。但据我所知，没有人强迫任何人接受这种通用设计。这只是我们都同意的。我认为同样的实用主义在计算领域也很有用。
HIG 如何应用于 Unix Shell 应用程序？
在某种程度上，HIG 是由 Shell 应用程序使用的库和它们运行的环境强制施加的。如果我编写一个在 BASH 或 (t)csh 或类似的 Shell 中运行的 Unix 应用程序，那么参数 $0 几乎必须是可执行文件的名称（这并不意味着键入的第一个字符串必须是参数 $0，就像在 BASH 中将 ENV 变量传递给命令的情况一样）。这是一件好事，它是那些不容置疑的实用指南之一。如果有人设计了一个首先查找参数的 Shell，我想那将是新的事物，并且最初可能会让大多数用户感到困惑。
然而，除此之外，还有很大的灵活性，例如选项和参数的顺序，是否期望提示确认等等。有些事情是大多数 Unix 用户期望的，但这并不总是事情的运作方式。
我认为，聚集在一起，确定什么是“有道理的”，以及在设计应用程序时什么是最有道理的，是有帮助的，无论该应用程序是供个人使用的简单 BASH 脚本，还是 Python 或 C++。
我认为，现在开源以及免费的 Unix 和 Linux 传统变得如此流行，这一点尤其重要。毫无疑问，已经出现了一些糟糕的 Unix 实现；我希望我们能够通过一些智能设计共同同意避免这种情况。
HIG 应该适用于使用参数和选项的 CLI 命令和应用程序，以及菜单驱动的应用程序吗？
不应该使用相同的 HIG，但应该有一些非强制性的指南。
话虽如此，但我们对两者中的某些指南都习以为常。许多 GUI 应用程序努力从左上到右下工作，这是一个指南。同样，我们倾向于从左到右构造命令，通常假设顺序是 COMMAND > SOURCE > DESTINATION。这一定是构建事物的最佳方式吗？应该暗示一个顺序吗？值得思考！
Unix Shell 应用程序最重要的 HIG 指南有哪些？
Shell 应用程序最重要的考虑因素包括：
- 命令是否以纯文本形式工作？还是它有界面（ncurses 或其他方式）？它能两者兼顾吗？
- 应用程序是否强制执行特定的选项和命令顺序？如果是，用户如何知道？是否有某种人性化的分隔符来帮助人们记住参数需要在等式的哪一边才能产生预期的结果？
- 命令是否接受来自 stdin 的输入？
- 命令是否可以写入 stdout？
- 命令是否在明显的错误语法上提供有用的反馈？命令是否可以提供有用的反馈来防止错误语法？
- 命令是否是交互式的？是否有开关来打开或关闭它？
- 我可以在命令中覆盖重要数据（如配置文件）的位置吗？
- 命令是否为信号（HUP、USR 等）提供独特的响应？
你能举例说明哪些 Unix Shell 应用程序符合 HIG 以及为什么吗？
简短的回答是来参加[我的]演讲，找出答案！
长答案是 HIG 是一件大事，并且根据每个命令的目标而独特地适用。因此，我感觉有很多命令用起来很愉快。当你键入它们时，它们会顺畅地从你的手指间流出；语法几乎是自我展现的。但是，你用命令所做的事情可能会令人困惑，因此它可能不会让人感到非常友好，仅仅是因为你并没有真正理解你在做什么。
所以这是一件复杂的事情，我认为答案不是指向一个真实的或想象中的“完美”命令，而是定义一套合理的期望，并在它们适合命令的自称目标时应用它们。
这有点像评论电子游戏。你可以将益智游戏与 RPG 进行比较，但你不能真正根据其中一个来判断另一个，因为它们都朝着独特的目标努力。Unix 命令在某种程度上也是如此；并非所有东西都应该以相同的方式工作，但一切都应该根据它们自己建立的规则集来理解。
而且最重要的是，一切都应该像预期的 Shell 应用程序那样工作。
你是否有特别的 Unix Shell 应用程序完全无视 HIG，为什么？
我有一两个，但没有必要指名道姓，不仅因为我可能（或可能不）认识它们的作者，还因为这些命令本身可能正在做着令人惊奇的事情。希望在这种情况下，开发人员会参加我的演讲，回家后思考一下他们的命令与其他命令相比如何。
但是，我要指出鲜为人知的[并且纯粹是假设的]命令 `hijinx`。这是一个令人憎恶的命令，我害怕使用它，而且由于它的作者在一场涉及过于热情的 CPU 风扇和功率过大的万用表的离奇事故中丧生，所以批评它不会造成真正的伤害。
例如，假设我们使用 hijinx，它令人困惑地提供了可执行文件 `hijink` 而不是 `hijinx`（我认为作者认为单数“hijink”比他的项目的复数名称更合乎逻辑）
$ hijink bar baz
只要我们完全按照这个顺序使用它，它就能很好地工作：命令、选项、参数。但是如果我们这样做
$ hijink baz bar
它就会失败。这很烦人，因为如果 'bar' 值是我发现自己最常更改的值怎么办？作者强迫我按向上箭头，然后按 alt-b，然后按 alt-d，然后键入新选项，这似乎很小气。
想想如果我可以这样做会好多少：
$ hijinx -baz -o bar
$ hijinx -o bar -baz
并且每次都得到相同的结果？
与 GUI 相比，Unix Shell 是否强制人机界面遵循有限的指南子集？如果是，如何强制？
凭直觉，我会说它甚至不是一个子集。我认为它更可能是一个不同的集合。我确信在这方面有两种说法。我从来没有以这种方式考虑过。
重点与其说是关于明确定义的 HIG，不如说是关于它代表什么：人机界面指南。它是关于思考你的用户，他们对界面的期望，以及开发人员可能希望做些什么来使界面减少障碍，增加趣味性。
底层操作系统对 Unix Shell 施加了哪些类型的用户界面限制？
我对非 POSIX 操作系统了解不多，所以不能确定，但我能想到的唯一一个是 Unix 信号，以及可能使用管道处理 stdin 和 stdout（我读到 Powershell 有管道，但从我所看到的来看，它们在技术上与 Unix 管道不同，但我显然没有查看代码甚至没有使用过 Powershell，所以我不能确定）。我现在能想到的其他一切都由 Shell 本身（BASH 或 tcsh 或 ksh 或 zsh）或你用来解析参数的方法（if/else 检查、解析库、何时处理参数等等）处理。
HIG 如何影响系统管理员的日常任务？
这取决于相关的系统管理员在做什么。可用性的美妙之处在于，一旦你学会了某种东西，可用性就会从视野中消失。你知道如何使用应用程序，你知道它是如何工作的以及你必须克服什么困难。
但是，当你学习新事物时，这种情况就会瓦解。那时可用性往往最重要。
重复操作有时也会暴露糟糕的界面。显然，如果你不得不一遍又一遍地做某事，并且它强加了笨拙的解决方法，那么你就会开始渴望一些人机界面上的理智。
你希望通过你在 ATO 上的演讲实现什么目标？
我希望开发人员和即将成为开发人员的人员参加演讲，并思考如何通过仔细考虑界面设计来加强他们的应用程序。对鹅好的东西可能对公鹅不好，因此，一个灵活的命令，具有合理的语法，至少在良好的内部逻辑与 Shell 用户的期望之间取得平衡，是一个人们和理想情况下发行版都会乐于采用的命令。
我们的读者可以去哪里了解更多关于 HIG 的信息？
无处可去，因为 Shell 还没有 HIG...。要了解 Shell 是如何发展的，以及为什么我们倾向于以我们做事的方式做事，我强烈推荐 Mike Gancarz 的 The Unix Philosophy 和 Linux and the Unix Philosophy。它们绝不是直接关于界面设计的，但这些书部分解释了为什么 Unix 如此成功地以其工作方式工作，并且在为 Unix Shell 编程应用程序时可以考虑很多因素。
演讲者访谈
本文是 All Things Open 演讲者访谈 系列的一部分。 All Things Open 是一场探索企业中的开源、开放技术和开放网络的会议.
4 条评论