On Mon, 05.05.14 10:35, Kaleb S. KEITHLEY (kkeithle@redhat.com) wrote:

On 05/05/2014 10:28 AM, Adam Jackson wrote:

On Sun, 2014-05-04 at 18:59 +0200, Reindl Harald wrote:

however, the semantics of /usr/sbin is to contain superuser
binaries which should not be overriden because a binary
with the same name exists in /usr/bin

My memory is that the "s" was more for "static" not "superuser".
There's some conceptual overlap, static binaries being there to recover
even if your shared libraries are hosed which is normally a "superuser"
kind of operation, but.

My recollection is that the "s" in /sbin and /usr/sbin was more
"system" level management. Things an admin would need but would not
usually be needed by an ordinary user.

Binaries in /bin and /sbin would have been statically linked to aid
in recovering a system in single-user mode when /usr might not be
mounted, in the days when disks were so small that /usr might often
be a separate disk.

/usr/sbin is an invention of Linux.

The traditional SysV meaning is /sbin for static binaries, and /bin for
and /usr/bin for normal dynamic binaries. Linux then redefine "sbin" as
meaning "system binaries", but that's a concept that really doesn't make
much sense, as you can see for example by Fedora always placing both
/usr/bin and /usr/sbin in the $PATH, and shipping a number of binaries
in both places...

We really should get rid of the destinction, and make all of /bin,
/sbin, /usr/sbin a symlink to /usr/bin, and then never bother again
about $PATH orders and namespace collisions...

Lennart