|
On 05/05/2014 10:43 AM, Lennart
Poettering wrote:
It existed in *BSD for as long as I used it.On Mon, 05.05.14 10:35, Kaleb S. KEITHLEY (kkeithle@xxxxxxxxxx) 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/binMy 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 --
Stephen Clark NetWolves Managed Services, LLC. Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark@xxxxxxxxxxxxx http://www.netwolves.com |
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
