On 24Jul2019 22:57, Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> wrote:
On 7/24/19 10:24 PM, Michael Torrie wrote:
... 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. 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).
On ancient file systems (SysV?), ISTR something like 1400 files in a
directory being some sort of limit, or perhaps a major performance
issue. Separate directories (including /usr/X11/bin) mitigated that,
too.
I don't recall there being any specific hard limit though. What does
happen in decent modern filesystems is that directories have a hash
table in them for lookups, making a file name access constant time
instead of a linear search.
Also, shells like zsh keep a hash table of the available commands to
speed invocation, avoiding a linear $PATH search.
I don't recall stuff like /usr/X11/bin being aimed at performance (but I
would not necessarily know); it has always seemed more like partitioning
out various software groups - in this case the X11 Window System stuff.
If nothing else, this makes separate development easier.
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.
My .shrc file has all sorts of leftovers from the old days, but my
current Linux PATH is just $HOME/bin, $HOME/local/bin, and /usr/bin.
Hmm. 21 componetent in my $PATH here :-)
Cheers,
Cameron Simpson <c...@cskk.id.au>
--
https://mail.python.org/mailman/listinfo/python-list
