David Mansfield wrote:
>> in the right order:
/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin.
Are you aware that that is not the same root's path, and the whole idea
was to take away the distinction of 'this program works like foo if I am
root, but bar if I'm a user'... And also, the 'su -' works and 'su'
doesn't problem. And the path with 'su -' is:
(some kerberos etc. garbage stripped out):
/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
It seems like your suggestion at least has the following problems:
* /usr/local/[s]bin needs to come before anything
* the 's' variants should come before the non-s variants
* console-helper should be fixed if it's so broken as to require the
path order to be different for different classes of users to work
properly, or simply, have console-helper drop the /usr/sbin component
and move it to /usr/libexec which is the normal convention.
The first point is definitely true, the second two are only possible
true ;-)
I still think all reasons for having a separate /sbin are obsolete and
at some future point in new installations it would be better to replace
it with a symlink pointing to /bin (noting that this can't be done
cleanly at runtime in an update). That means that any packages that are
currently symlinked into to both should be fixed to not care if the link
fails and any behavior differences between same-named programs depending
on their location should be fixed (unless someone still thinks that
surprises depending on whether you used "su" or "su -" are a good
learning experience). Meanwhile, changing the default user path fixes
the worst parts of the problem. But then there is the alias business
too... Should someone who normally uses "su -" but forgets and does
"su" be surprised to learn that rm really doesn't ask if you meant to do
that?
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
