手册页的节标题为什么不完整？

在El Capitan和同事的High Sierra（标准终端）中进行了测试（打击）。

user@hostname ~ $ man ls | grep "BU"
BUGS
user@hostname ~ $ man ls | grep "BUG"
user@hostname ~ $ 
user@hostname ~ $ man ls | grep "IEEE"
     files in order to be compatible with the IEEE Std 1003.2 (``POSIX.2'')
     The ls utility conforms to IEEE Std 1003.1-2001 (``POSIX.1'').

需要说明的是：“ BUGS”是该（以及其他各种）联机帮助页中的部分标题。对于章节标题，grepping似乎仅对前2个字符有效；这在我们尝试过的几个不同章节标题中是一致的。对于其余的内容，grep似乎可以按预期工作。

我将其放入非BSD风格的Linux盒（Amazon Linux）中，它似乎没有表现出相同的行为。

这里发生了什么？

— 乔纳森·默克林
source

这是我讨厌BSD男人的部分原因。它格式化文本并运行寻呼机，即使其输出是管道也是如此。而且我的传呼机是vim，所以Linus禁止我做过man foo | grep bar，我得到了一个没有响应的管道（也许是一个混乱的终端来启动）。：/ mandb man，这是您在Linux上通常看到的，更明智。

— 大师

unix.stackexchange.com/questions/371062也是MacOS的问题。

— JdeBP

如果在手册页中查看原始代码，则可以看到发生了什么。一种方法是将手册页导出到文件并直接检查其内容：

man ls > man.ls
nano man.ls

文件中的“ BUGS”一词实际上看起来像这样：

B^HBU^HUG^HGS^HS

您会看到标题包含格式字符，因此不存在整个单词“ BUGS”。

如果要访问手册页的纯文本内容，可以使用以下命令

man -P cat <thepage>

该-P选项将寻呼机设置在其他UNIX上，并且cat将忽略格式信息，并提供纯文本输出。但是，这似乎在macOS上不起作用，因此输出需要col -b在管道中进行手动操作：

man ls | col -b | grep BUGS

— 苏格兰人
source

谢谢苏格兰人！重定向到文件并在文本编辑器中打开应该是我尝试过的第一件事。使用这些信息，以及来自unix.stackexchange.com/a/15866的信息（即man ls | col -b | grep "BUGS"），我能够得到想要的东西。

— 乔纳森·默克林

天哪，黑体字是旧的TTY和打字机时代，知道它们并不能很好地对齐并且会沉积更多墨水，所以键入字母和退格键并再次键入字母。nroff如果需要，必须有一个命令来翻译该命令grep -如果我通过将正确的命令传递给groffvia 来扩展它，您介意man吗？

— bmike

@Kroltan +10和+10也要苏格兰语。这比我没有想到要给这只猫剥皮更优雅。

— bmike

@Kroltan Hmmm-对我来说，man -P cat ls | grep BUGS与的工作方式相同man ls | grep BUGS，两者均不返回任何内容。

— 苏格兰人，

对于使用GNU roff的手动系统，确实有一些选择grotty可以阻止它发出TTY-37或ECMA48控制序列。

— JdeBP