LWN：Debian man文件中的各种破折号！

关注了就能看到更多这么棒的文章哦～

Hyphens, minus, and dashes in Debian man pages

By Jonathan Corbet
October 23, 2023
ChatGPT translation
https://lwn.net/Articles/947941/

关于排版程序 troff，可以说大多数 Linux 用户很少花时间关注，尽管这个应用在计算机历史中起到了开创性的作用。Troff（nroff 也是一样）至今仍在使用，尽管现在它们被称为 groff，并且偶尔会引起关注。最近 groff 的一次更改在 Debian 社区内引起了轩然大波，并在那里被撤销。归根结底的问题是在 Unix 系统上用什么字符来标记命令行选项。

去年七月，Sven Joachim 提出了一个 bug 报告，关于 groff 的更改以及它如何在终端上呈现 man 页面。对字符的处理，通常称为 "连字符"、"减号" 或 "破折号" (看起来都是"-"，但是分别名为 hyphen，minus，dash)，使许多 man 页面变得更难处理。为了理解这个问题，先介绍一下 Unicode 提供了许多类似的字符，其中一些是：

Name	Codepoint
Hyphen-Minus	002D	-
Hyphen	2010	‐
En Dash	2013	–
Em Dash	2014	—
Minus Sign	2212	−

Unicode 在这方面非常慷慨，甚至还有更多的其他字符。这里将使用术语 "破折号（dashes）" 来指代这类字符。

groff 的指定行为是，输入中的 ASCII "-"（连字符减号，hyphen-minus）变成输出中的 hyphen 符号。如果希望在输出中使用连字符减号，则输入应该使用序列 "­"。如果 man 页面的作者输入 "–frobnicate" 作为选项名称，输出将显示 "‐‐frobnicate"（带有破折号），而不是 "–frobnicate"（使用连字符减号）。两者看起来一样，但有一个关键的区别。在 man 页面中搜索 "–frobnicate" 的时候如果使用了错误类型的破折号，就完全找不到了，而且如果用户复制并粘贴一个带有错误破折号的示例，也无法生效。

例如，可以尝试将以下两行粘贴到 shell 中：

/usr/bin/echo --help
/usr/bin/echo ‐‐help

其中一行的结果将比另一行提供更多帮助信息。使用错误类型的破折号还可能破坏 URL 并损坏文件名。

当然，自由软件的开发人员在非常勤奋地编写 man 页面；他们迅速完成工作，花时间确保每个细节都正确，并且可以期望在每种情况下都使用正确类型的破折号，即使使用错误类型的输出看起来完全相同。尽管使用一个旨在记录命令行选项的格式包含一个陷阱，也就是未添加反斜杠导致远在天边的一个用户碰到麻烦，但开发者肯定不会感到困扰。

令人震惊的是，事实并非如此，Linux 的 man 页面中充满了未转义的破折号。几年前，Debian 项目尝试通过将其 Lintian 工具添加一个检查，以在使用未转义的破折号时发出警告来解决这个问题。然而，这个检查在 2015 年 被放弃，因为 Niels Thykier 得出结论说它已经完全被忽略了：“该标签自 2004 年以来一直存在（提交 fb2e7de）。到目前为止，仍然有 2000 个带有此问题的软件包。” 从那时起，当 man 页面包含未转义的破折号时，Debian 开发人员再也没有看到警告。

鉴于这个问题普遍存在，可能确实需要在处理这部分逻辑的代码上合入一个 fix 了。实际上，多年来，groff 已经在 man page 宏中重新映射了连字符减号字符（以及其他一些字符），使破折号字符可以跟许多人期望的那样来简单地工作。然而，这种有益的行为在 7 月份的 groff 1.23.0 版本发布 中结束了：

an（man）和 doc（mdoc）宏包不再将 -、' 和 ` 输入字符重新映射到 UTF-8 设备上的基本拉丁字符，而是像 groff 通常的处理方式一样（也是 AT&T troff 在它之前的处理设备上的方式），在排版设备上它们变成连字符、撇号或右单引号，以及左单引号。这一变化预计会在 man 页面中暴露出一些字符使用方面的错误。请参见 "PROBLEMS" 文件，了解一个如何隐藏这些错误的建议。长期来说更好的方法是 man 页面要采用正确的输入方式。

问题确实暴露出来，用户开始抱怨，并提交了 bug，并且这个话题还出现在了 debian-devel 邮件列表上。groff 的上游维护者和这一更改的作者 G. Branden Robinson 为新行为辩护：

将所有连字符和减号符号映射到一个字符，就像那些因这个问题而血压飙升的人倾向于提倡的那样，是一个必定会丢掉一些信息的操作。在我看来，man 页面源文档不是丢弃这些信息的正确地方。

其他人则不同意 Robinson 的立场；Russ Allbery 表示：

我认为由 man 处理的文档领域在 - 和 ­ 之间做区别对待是没有意义的，因此 man 应该统一这些字符。

Colin Watson，维护 Debian 的 groff 包的人，承认在更新 Debian 到 1.23.0 版本时他忽略了这个问题：

我知道这个改动，但在打包 1.23.0 时，它在我的需要决策的清单中不知何故被遗漏了。我更倾向于通过将上述 recipe 的其余部分添加到 debian/mandoc.local 中来撤销此更改（尽管我同意所提出的印刷错误的理念，但在实践中修复整个发行版的 man page 任务完全不是我的乐趣所在）。

几周后，他表示他计划在当前 Debian 13（"Trixie"）开发周期内保留此更改，但在预发布冻结之前撤销它，以避免给 Debian 的用户带来问题。理论上，这将给开发人员时间来尽可能修复问题。然而，讨论进行了一段时间后，他改变了主意，表示他不愿意在接下来的一年里让他的收件箱充满这个讨论。因此，“-”已经被改回去了，Debian 版本的 groff 已经回到了过去的方案。

这个小插曲很可能会在其他发行版中重演，等它们也采用 groff 1.23.0 版本的时候。在 Debian 内部，这个情况可能还没有结束。这种情况将文档编写、印刷正确性和 Unicode 外观相似的字符的问题搅和在了一起，所有这些都是容易引发争议的领域。尽管希望通过在 groff 中去除重新映射来修复所有这些 man 页面的问题可能已经破灭，但这并不妨碍将来的另一次尝试。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～