JC 将流行命令行工具的输出转换为 JSON

原文 ↗ Hacker News 讨论 ↗

许多开发者希望传统 Unix 命令行工具能输出像 JSON 这样的结构化数据，而不是临时拼凑的文本，这样自动化和日志解析会容易得多。`jc` 项目通过将数十种现有命令的输出转换为 JSON 来应对这一需求，被赞为务实的过渡方案，但也因工具和格式演进而带来长期维护风险。参与者将这种做法与 PowerShell 的对象管道、FreeBSD 的 libxo、journald 以及像 Nushell 这样的新型 shell 进行比较，并且不少人认为核心工具最终应以原生 `--json` 支持取代外部解析器。

对 jc 的总体反应

  • 许多人觉得这个想法非常吸引人：提供一种通用方式，把经典 CLI 输出转换成 JSON，以便与 jq、Nushell 或 PowerShell 等工具一起使用。
  • 它被视为一种务实的过渡方案，直到更多工具原生支持 --json（或类似）输出。
  • 一些用户已经将它与其他结构化 shell（例如 Nushell、PowerShell）搭配使用，并且很喜欢这种易用性。

对结构化 CLI 输出的需求

  • 强烈支持在 Unix 工具中提供标准的 JSON（或 JSONL / NDJSON）输出标志，例如 --json、-j。
  • 与以下方案进行比较：
    • PowerShell 的“万物皆对象”管道。
    • FreeBSD 的 libxo 以及 SerenityOS 的 /proc 中 JSON 方式。
    • journald 的 journalctl -o json。
  • 提到了几个现有的支持 JSON 的工具示例：ip、kubectl -o json、lsblk --json、TShark、AWS CLI（大多如此）、通过 libxo 的 FreeBSD 工具。

关于解析与维护的担忧

  • 对长期可维护性持怀疑态度：
    • 输出格式会因版本、标志和环境而变化。
    • 解析器中的假设可能会在更新后失效。
  • 反驳观点：
    • 核心 Unix 工具和许多文件格式都很稳定，几乎不会改变。
    • jc 支持插件，将部分维护工作交给社区。
    • 作者表示实际出现的破坏情况相对较少；大多数问题只是小的边缘案例。

替代方案与相关做法

  • 有人认为，上游工具应该直接实现结构化输出，而不是依赖包装器。
  • 也有人喜欢把解析逻辑集中到专门工具中（jc、libxo、TXR、textfsm），避免到处临时写 regex/awk。
  • Nushell 被强调为一种替代方案，它从设计上就把命令结果当作结构化数据处理。
  • PowerShell 因对象管道而受到赞扬，但也被批评为复杂、不一致，并且与 .NET 紧密耦合。

关于 LLM 与解析的争论

  • 一派建议使用 LLM 来解析任意文本，甚至生成解析器，强调较低的开发成本。
  • 另一派强烈反对：
    • 过度设计、效率低、难以验证，而且容易出现非确定性错误。
    • 在这个领域，手写解析器或简单的基于规则的解析器被认为更可靠。

更广泛的 Unix 哲学反思

  • 讨论涉及：
    • “纯文本” Unix 管道的局限性。
    • 对更丰富的数据类型（数字、日期）以及更好的 schema/versioning 的需求。
    • “保持工具简单”与“现代化结构化接口”之间的张力。