On 24Jul2019 20:24, Michael Torrie <torr...@gmail.com> wrote:
On 7/24/19 4:20 PM, Cameron Simpson wrote:
That is some progress, hooray. Then there's just sbin -> bin to go.
I suppose in the olden days sbin was for static binaries, usable in
single user mode for recovering the system without the main drive
mounted.
Yep. Happy days.
In more recent times, binaries that are mostly applicable to
the super user go there. I don't see why you would want to merge those.
A normal user rarely has need of much in /sbin.
I say unto to you "ifconfig". And, frankly, _any_ sbin command which can
be meaningfully run as nonroot, particularly for reporting.
I have always found this "oh its for root" distinction pretty vacuous,
and outstandingly annoying when basic system querying stuff isn't in the
default $PATH because of this. Maybe it is because I've been a sysadmin
for many years, but most physical machines are personal machines these
days anyway - we're our own sysadmins.
Already /bin has way>too much stuff in it (although I don't see any other way
to practically
do it without ridiculous PATHs searching all over the disk).
Like modules with many names, the number of things in /bin or /usr/bin
is generally irrelevant. Nobody does an "ls" in there without expecting
a fair amount of stuff - like imports, we invoke commands by name. Who
_cares_ how many names there are?
Having said that, I note that on my CentOS 7 workstation, sbin seems to
be in the path by default. So that negates my argument I suppose.
Although I might have made that change myself.
I have historically had to add it to my $PATH on most platforms.
Cheers,
Cameron Simpson <c...@cskk.id.au>
--
https://mail.python.org/mailman/listinfo/python-list
