命令行界面指南（2021）

CLI vs TUI vs GUI

• 有些人认为 TUI 非常适合“普通用户”：字体大小一致、布局密集但结构清晰、键盘效率高，而且对 SSH 友好。
• 另一些人反驳说，TUI 也共享了许多 GUI 的缺点，并不更易于发现；设计良好的 GUI 可以在不受终端限制的情况下模仿 TUI 的结构。
• 还有几位提到，CLI 在绝对用户数量上正处于“黄金时代”，但争论焦点在于，相对于所有计算机用户，它们是否更重要。

Shell、组合与 POSIX 工具

• 关于 Unix 命令主要是为程序化使用还是交互式 shell 使用而设计，存在争论；大家一致认为 shell 是编程语言，但并不适合大型程序。
• 对“shell 作为胶水”的支持很强：用极小的 shell 脚本来编排 C 或其他二进制程序，可以替代大得多的程序。
• POSIX getopt 被广泛提及，但需要澄清它是 POSIX 特性，而不是语言特性。

命令行设计惯例与痛点

• 对嵌套子命令层级的看法不一：它们可以降低局部复杂度，但会让发现功能比一个大的帮助页面更困难。
• 对标志位大小写不一致和短旗标组合的抱怨很多；有些人希望新工具更偏向长而明确的标志，并避免棘手的短选项语义。
• 有人呼吁避免任意的子命令缩写，尤其是在脚本中，以保持未来的可扩展性。
• 有些人觉得这份指南文档很长，另一些人则认为相较于典型的 UI 指南，它其实很简洁。

机器可读输出与格式

• 人类可读与机器可读 CLI 之间的张力被称为“设计上有缺陷”；建议包括 --json 模式和/或 IO 格式环境变量。
• 有人担心环境变量既能简化全局控制，也会引入微妙的 bug 或臃肿。
• PowerShell 被提为一种部分解决方案，因为它支持结构化输出，但也因冗长且有时难以使用而受到批评。

安全、dry run 与破坏性命令

• 大力支持 --dry-run / “what-if” 行为，有时甚至希望它成为默认值，而需要显式的 --execute / --commit。
• 建议的模式包括：
  • 只输出 shell 命令的工具，让用户先检查/编辑，再通过管道传给 sh。
  • 通过覆盖文件系统实现 try 式沙箱。
• 有些人会重写核心工具以加入安全提示；另一些人则更喜欢带 -i 的 shell 别名。

机密信息处理

• 关于“不要把秘密放在环境变量里”的准则存在争议。
• 讨论的替代方案包括：权限严格的凭据文件、systemd credentials，以及“运行这个命令来获取 secret”的钩子，它们可以委托给密码管理器或服务。
• 在受管理环境中，secret manager 被认为很方便；但在个人项目中则不那么明确。

帮助、文档与可发现性

• 对于那些拒绝将 -? 或类似选项作为帮助，而只是打印用法的工具，人们感到不满。
• 有些人对指南仅仅说“考虑”使用 man page 感到失望；另一些人指出，对于大型 CLI，man page 和丰富的 --help 仍然至关重要。

Stdout/stderr 与输出体验

• 有强烈观点认为，所有日志、进度、动画和状态消息都应放在 stderr；stdout 应保留给“主要结果”，以保持管道的可靠性。
• 尤其批评了非 TTY stdout 上的动画，因为这会破坏日志；有人认为动画根本不应出现在 stdout 上。
• Emoji 和装饰性符号颇具争议：有些人觉得它们有帮助且便于快速浏览；另一些人则不喜欢不一致、终端渲染问题以及看起来轻浮，建议它们应当可选，并且要有文字作为冗余。

版本控制、弃用与 CLI 复杂度

• CLI 的弃用被认为格外困难，因为命令会立刻被脚本化，而且不像库那样具备版本固定语义。
• 有人讨论了把二进制复制到私有路径之类的变通方法，但也批评它们由于依赖关系而很脆弱。
• “mega-CLIs”（例如拥有多个子命令的工具）的增长令人遗憾，因为这背离了经典的 Unix “做好一件事”理念，但也被承认为是应对现代复杂性的务实回应。