On Mon, 05.05.14 10:35, Kaleb S. KEITHLEY (kkeit...@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 -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
