On Thu, Mar 30, 2006 at 04:13:52PM +0100, George Borisov wrote: > Andrew Cady wrote: > > > > A little research reveals that the original AT&T Unix contained no > > /sbin; however, the traditional contents of /sbin were present in /etc, > > mixed with configuration files. 4.3BSD placed these files in /etc also, > > but 4.4BSD moved them to /sbin, reserving /etc for configuration files > > only. > > > > Apparently the BSD folks decided in retrospect that mixing binaries with > > configuration was a bad idea. But why not put them in /bin? > > Just a guess, but a lot of the commands in /sbin require root > privileges. If you put them in a separate place you can exclude them > from a user's path. The same goes for /usr/sbin I suppose. > > It's not perfect though: /sbin/ifconfig is very useful to non-root > users, but it's not in the path. Another example would be /sbin/lsmod > (which a non-root user would need to get help on the mailing lists ;-) well i don't think a normal user (unless (s)he is also the system administrator) should need lsmod that often because in the case (s)he needs help, shouldn't (s)he ask his sysadmin/it support staff rather then figuring out himself what is configured wrong on thing like kernel modules? and _if_ (s)he should need it, that are seldom cases and it is therefore no problem to enter the full path... because in my expience there _is_ a performance problem whith a long path (especially with command completion...) and also whith command completion, a user might get confused if (s)he gets lots of commands (s)he can't execute or use...
yours albert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
