Manoj Srivastava <[EMAIL PROTECTED]> writes: > Manoj> The /bin vs /sbin distinction is purely about avoiding > Manoj> inconvenience and/or confusion for the normal user. The sole
Actually, this is incorrect. On platforms predating FHS/FSSTND, /sbin was for statically-linked binaries -- versions of vital system tools (fsck, sh, etc) linked statically for repair in an emergency. You may recall I have advocated having a few statically-linked binaries in Debian packages in the past. > Manoj> thing accomplished by putting some things in /sbin rather > Manoj> than /bin is that if you don't put /sbin in your path, you > Manoj> won't see those things. I myself, probably like most people > Manoj> on this list, rarely notice the distinction since I do have > Manoj> /sbin and /usr/sbin in my path. But the idea is that the > Manoj> average user won't have /sbin or /usr/sbin in their path, and > Manoj> so the programs in those directories can have simple names > Manoj> for the convenience of those who do use them, without an > Manoj> average user either accidentally running one because it has a I don't see very many (any?) commands in /sbin that could cause harm to the system, much less the user, if run accidentally by an average non-root user. I think the value is of organizing binaries -- this is why we have a hierarchial filesystem, after all. > You have also, perhaps correctly, classified me as an old > fashioned curmudeon who is wildly conservative. Perhaps. I do tend to > resist change merely for the sake of change, or for benefits that I > believe are unpalpable compared to compatibility and tradition lost. I might say that on occasion you tend to resist change merely for the sake of resisting :-) Anyway, I think the current situation is largely fine, although I am still dismayed by the lack of statically-linked binaries in /sbin.
