This means that in practice people will just add sbin to PATH to get a somewhat usable system, which makes the division between bin and sbin useless.

Furthermore, on BSD derived systems binaries that should not be invoked by users directly (e.g., daemons) need to be stored in libexec.

> Utilities used for system administration (and other root-only commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin.

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html

You may be thinking of the /bin and /usr/bin difference, though.

But I have only ever seen historic references to that argument, from back when dynamic linking was scary and unreliable. I certainly have never encountered that situation in almost 25 years of using Linux.

My memory is hazy but I recall the distinction being / vs /usr not /bin vs /sbin.

Having mnt be statically linked makes it much easier to recover that system.

The ideal of "/sbin for system tooling" isn't so much one of static vs dynamic but rather users accidentally finding system tools that don't work and sending email to the admin saying "mnt gives me a permission denied error" when they have no business running it.

    $ file /sbin/* | grep "dynamically linked" | wc -l
    325

    $ file /sbin/* | grep -i "static" | wc -l
    0

And why shouldn't they?

It's not as if a user could do anything damaging with them, if the system is setup properly.

> Having only usable binaries in the path aids discoverability of the system.

Except when someone new has to go online to ask "I found this tutorial telling me to use the `xyz` command to do this, but all I get is `bash: xyz: command not found`, please help!"

Most examples will include the standard user path plus /sbin and /usr/sbin but you can add any directories you want to the option.

But autocomplete after sudo doesn't work for me on a stock Debian install anyway, not sure what one needs to do to get around that. I don't really rely on it. If I'm doing enough work that needs root I start the session with "sudo su -" anyway so not having autocomplete after sudo is not a big deal for me.

Downside is it stops the autocomplete, so if you, say, wish to check quickly how binary is called on the system, e.g. if you should sudo apache2 or httpd, it will not work...

I think it's nice to be able to keep admin utils out of an admin's PATH when the admin isn't intending to use them.

It's much less interesting to me to keep daemons and such out of anyone's PATH if running them can't do much, though usually those things really belong in a libexec directory and should be exec'ed intentionally only.