[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Understanding /root, /usr, /var and so on

On Sun, Mar 26, 2006 at 02:32:51PM -0500, Kevin Mark wrote:
> On Sun, Mar 26, 2006 at 03:22:06AM -0500, Andrew Cady wrote:
> > The only reasons for having a separate /sbin are historical, and even
> > then they are unclear.  They certainly have nothing to do with security,
> > which is provided by other means.  Perhaps originally /bin represented
> > a stable interface for users while /sbin was allowed to be changed by
> > adminstrators?  *shrug*
> Hi Andrew,
> my cobwebbed brain always associates 'sbin' with 2 things: statically
> linked binaries and sysadmin binaries (which maybe statically linked
> to allow them to be used when you are in runlevel 'S' and only have
> /root and /)
> And 'bin' to be user binaries.

Well, /bin and /lib are always available in the root filesystem, and
/bin is at least as necessary for boot as /sbin.  While static linking
may be an advantage sometimes, it is pointless for /sbin unless /bin
is also statically linked; and of course there is /usr/sbin still to

I am really getting curious about this now.

btw, hier(7) says:

  Like /bin, this directory holds commands needed to boot the system,
  but which are usually not executed by normal users.
  This directory contains program binaries for system administration
  which are not essential for the boot process, for mounting /usr, or
  for system repair.

But this still does not really justify the special directory; why bother
to segregate commands not usually used by normal users at all?

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

Apparently the BSD folks decided in retrospect that mixing binaries with
configuration was a bad idea.  But why not put them in /bin?  It may
well have been performance reasons; that also seems to have been the
original reason for placing binaries in /usr/bin.  At least, AT&T unix
shipped everything in /bin, but recommended the administrator place most
of those commands in /usr/bin for faster performance on lookups in /bin.

Reply to: