Incorrect order of /usr/bin and /usr/sbin in path

[Steve Clark]

On 05/05/2014 10:43 AM, Lennart Poettering wrote:
> On Mon, 05.05.14 10:35, Kaleb S. KEITHLEY (kkeithle at 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.
It existed in *BSD for as long as I used it.

>
> 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 at netwolves.com
http://www.netwolves.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140505/1223a060/attachment.html>