最近，一位用户向我寻求帮助并写道：
“为什么调用会
man /bin/find显示乱码？”
man我回答说他通过提供路径来错误地使用，即将man可执行文件解释为手册页源文件，并且他应该只提供没有路径的主题名称，即man find.就在那时，他提出了一个让我难住的问题：
“那么，为什么如果我以 root 身份执行它会起作用呢
sudo man /bin/find？”
我尝试过，果然，当使用 root shellsudo或从 root shell 以 root 身份调用时，sudo man /bin/find显示手册页而不是可执行文件。
- 没什么特别的
find；这适用于任何可执行文件。 - 这种情况发生在 RHEL 7 和 8 上，但在 Mac OS 上，它将二进制文件显示为 root 或用户。
- 我在 的手册页中找不到对此的提及
man。 - 我做了一个现实检查：
ls -i man并sudo ls -i man返回相同的索引节点。同样对于/bin/find. man尚未被别名。- 在 shell中运行它
bash -x不会显示任何替换。
我肯定忽略了一些简单的事情；这种现象的解释是什么？
答案1
我已经测试过了，你是对的。您监督的是man /usr/bin/find显示页面，而不是二进制文件。不仅如此，如果您添加/bin到$PATH它，也会显示页面而不是二进制man /bin/find。您还可以检查真正的 root（不是 sudo）是否会显示二进制文件。
那么这里发生了什么：
Man如果此路径存在于 中，则从参数中删除路径$PATH。删除任何可执行路径不显示二进制文件似乎很明显man。也许他们没有其他方法将二进制文件与参数中的术语区分开来。- 为了防止运行未经授权的命令，sudo 在 EL 系统上有自己的定义，
PATH并且任何命令在另一个环境中运行。secure_path/etc/sudoers/sbin:/bin:/usr/sbin:/usr/binsudoPATH - 在 EL 系统中
/bin/find是硬链接/usr/bin/find，默认情况下/bin不会添加$PATH。这导致man不理解这是二进制的，但sudo添加/bin到$PATH所以man现在变得能够理解。