作为一个命令行爱好者，当我看到 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 的飞跃其实并没有那么困难。
话虽如此，我原本并不想从事计算机行业，而是想从事电影行业。我暗地里还是个技术宅，但我去电影学院学习电影制作。
有一天，在去电影学院的路上，我正在阅读一本行业杂志，上面有一篇文章介绍视觉特效公司如何使用 Unix，文章说他们有一种神秘的能力，可以在不启动界面的情况下启动程序。从那时起，我强烈好奇我如何也能在不费心使用实际 UI 的情况下使用应用程序。
当我得知我从小使用的操作系统是“基于 Unix 的”时，我买了一本关于如何学习 Unix 的书（具体来说是 Unix 视觉快速入门指南）。我开始将书中的所有内容应用到我在那个操作系统中找到的终端上。在 Emacs 的文档中，我当时主要将 Emacs 用作俄罗斯方块引擎，我了解了开源和 GPL 的概念。最终，我厌倦了持续不断的编译器错误以及无法在不需要桌面时避免启动桌面，所以我转到了 Slackware Linux，并且再也没有回头。
顺便说一句，我现在从事视觉特效工作。
Unix shell 最吸引你的是什么？
效率。我似乎对任何阻碍我实现既定目标的事物都没有耐心，而 shell 是所有计算事物中唯一能让我完全按照我的意愿行事的东西。
其次是创建我自己的工作环境的能力。这花了一段时间，但一旦我学会了脚本编写的基础知识，编写自定义命令和脚本的能力彻底改变了我的生活。
有很多其他好的理由来热爱 shell，但就目前而言，这两点是最能引起共鸣的。
HIG 代表什么？
“HIG”是我从 GNOME 那里学到的一个术语。它代表“人机界面指南”，它是一套规范，建议开发人员应用程序应如何向人们呈现其功能。
你是如何对人机界面指南产生兴趣的？
广义上讲，我认为我对这个话题不是很感兴趣，至少不像 UI 设计师那样感兴趣。但是所有计算机用户都对人机界面指南有点感兴趣，因为这是我们使用计算设备的方式。对我来说，这只是一个关于我们应该如何集体地，至少在某种程度上，同意计算机应该如何工作的问题。这是我们努力在应用程序的使用方式上形成共同趋势的尝试。
我不知道汽车制造商是如何做到的，但一般来说，如果你进入一辆汽车，即使是新西兰的汽车（驾驶座在左边），你基本上也知道所有东西都在哪里。但据我所知，没有人强迫任何人接受这种通用设计。这只是我们都同意的。我认为同样的实用主义在计算中也很有用。
HIG 如何应用于 Unix shell 应用程序？
在某种程度上，HIG 是由 shell 应用程序使用的库和它们运行的环境强加给它们的。如果我编写一个在 BASH 或 (t)csh 或类似的 shell 中运行的 Unix 应用程序，那么参数 $0 几乎必须是可执行文件的名称（这并不意味着键入的第一个字符串必须是 arg $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 的 UNIX 哲学 和 Linux 和 UNIX 哲学。它们绝不是直接关于界面设计的，但这些书部分解释了为什么 Unix 如此成功地以它现在的方式工作，并且在为 Unix shell 编程应用程序时可以考虑很多这些方面。
演讲者访谈
本文是 All Things Open 演讲者访谈 系列的一部分。All Things Open 是一个探讨企业中的开源、开放技术和开放网络的会议.
4 条评论