Recently a user asked me for help and wrote:

"Why does invoking man /bin/find display gibberish?"

I answered that he was using man incorrectly by providing a path, that man was interpreting the executable as a man page source file, and that he should only provide the name of the subject without a path, i.e. man find. It was then that he sprang the question that stumped me:

"Well then, why does it work if I do it as root, i.e. sudo man /bin/find?"

I tried it, and sure enough, when invoked as root using sudo or from a root shell, sudo man /bin/find displays the man page instead of the executable.

  • There's nothing special about find; this works for any executable.
  • This occurs on RHEL 7 and 8, but on Mac OS it displays the binary as root or user.
  • I can find no mention of this in the man page for man.
  • I made a reality check: ls -i man and sudo ls -i man return the same inode. Same for /bin/find.
  • man has not been aliased.
  • Running it in a bash -x shell does not reveal any substitutions.

Surely I've overlooked something simple; what is the explanation for this phenomenon?

  • 2
    man /bin/find works for me as a regular user (Ubuntu 20.04, bash and zsh, CentOS 7). Commented Sep 13, 2023 at 6:35
  • Thanks for adding another data point.
    – Thagomizer
    Commented Sep 14, 2023 at 18:57

1 Answer 1


I've tested it and you are right. The thing you overseen is that man /usr/bin/find display page, not binary. More than that if you add /bin to $PATH it will display page instead of binary for man /bin/find as well. You also can check that real root (not sudo) will display binary.

So what is happening here:

  1. Man strip path from the argument if this path present in $PATH. It seems to be quite obvious for man to strip any executable path not to display binary files. Maybe they have no other way to distinguish binary file from term in argument.
  2. To prevent unauthorized command being run sudo have its own PATH defined in secure_path in /etc/sudoers which is /sbin:/bin:/usr/sbin:/usr/bin on EL systems and any command run by sudo have another PATH environment.
  3. In EL systems /bin/find is a hardlink for /usr/bin/find and /bin is not added to $PATH by default. This cause man not to understand this is binary, but sudo add /bin to $PATH so man now become capable of understanding.
  • 2
    I don't think that sudo changes /bin/find to /usr/bin/find. It's an argument to the command and sudo shouldn't change arguments. I guess the real reason is that sudo resets $PATH and adds /bin to it. And now man sees that /bin/find is a command in $PATH and not just a random file.
    – Alexey Ten
    Commented Sep 13, 2023 at 10:05
  • 1
    It certainly does. Make restriction to /bin/systemctl and hardlink for it and then call sudo ./systemctl. However you are right that sudo changes PATH variable, and questioned mechanism works your way, not mine. Thanks. My initial thought have no sense since /bin/find is not an executed element here, only man is.
    – kab00m
    Commented Sep 13, 2023 at 10:18
  • 2
    I believe it changes man to /usr/bin/man. But I really doubt it changes man's arguments.
    – Alexey Ten
    Commented Sep 13, 2023 at 10:26
  • 1
    Surely, I just read your comment not thoroughly, sorry. Thanks again.
    – kab00m
    Commented Sep 13, 2023 at 10:33
  • 1
    @kab00m Did you find documentation about man's path-stripping behavior, or deduce it?
    – Thagomizer
    Commented Sep 14, 2023 at 18:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .