Date:        Sun, 08 Jun 2003 18:14:07 -0400
    From:        William Allen Simpson <wsimpson@greendragon.com>
    Message-ID:  <3EE3B521.6A302CAB@greendragon.com>

  | I also checked the files against those in the new /rescue.  After all, 
  | something necessary to "rescue" the system is probably needed in 
  | single user mode!

No, I don't think that's true at all - but just what "single user mode"
is being referred to seems to be the real issue here.

That is, I regard /bin and /sbin are being the home for commands that the
system has to have available in order to get the rest of a normal system
functional (that is, to complete the boot process - the "single user mode"
that every unix system transitions through before coming up multi user).

I don't believe that it should contain every command that some random
administrator might decide is needed when they do "boot -s" and sit in
that state for half a day.   There's no limit to what might be needed
there (after all, this thing I am in single user mode to do might take
hours - while waiting, I need games to play, which means I also need X,
which means ...)

If the right things are in /bin and /sbin, then after booting to single
user mode in the latter sense (boot -s), the administrator can trivially
easily get all the rest of the commands as well (like "fsck -p", "mount -a")
if they're needed (I very frequently "mount /usr" when I am going to
be in single user mode for more than a few minutes).

On the other hand, /rescue is for all the stuff which is needed if your
filesystem is hosed, and you need to recover it.   So, there's no rational
need for tar/pax/cpio in /sbin or /bin (they're not needed in any way to
get from single user to multi user, no matter what environment) but they
are going to be needed in /rescue (along with lots more).

It is reasonable for /rescue to contain almost anything that might be
useful when /rescue is all that is working.   The caveat that it has that
stability is more important there than the latest functionality, and
even the latest bug fixes (if it worked well enough to ship, it works
well enough for /rescue forever - no matter what bug someone discovers
later, including security bugs).   It is also reasonable for /rescue
versions of programs to have limits on their functionality (if the sh
that is there has no line editing, for example, that's OK, in the rare
case that /rescue is needed, I'll be thankful enough that it exists that
I won't care if I have to do a little extra typing - and note: I am not
saying that that particular function is disabled in /rescue, that is
just a hypothetical example).

The real issue is why so much junk is currently in /sbin and /bin when
it really has no justification for being there.

Eg: /bin/test (and [ or course) are unnecessary, sh has test built in,
and all the boot time scripts do (or easily could, and should) use that
instead.

But - /bin/test has been /bin/test for eons, and people who have wanted
to avoid the built in test in the shell (some versions of which have had
a history of not being very good) have just used /bin/test in the script
to force the command to be run instead of the builtin.   Hence, test
remains in /bin.  There are a bunch more like that.

  | Of these, chgrp is in /rescue, and required for /bin by FHS.

I cannot imagine anything which I would ever need to chgrp or chown
during system startup which didn't qualify as a system rescue, so no,
they don't belong.

  | Arguably, eject might be important during system maintenance?

Anything is arguable (there's a vociferous member of this list who
demonstrates that frequently) but this one?   Someone really needs
a tool to perform an action that is essentially useless without
physical access to the system, which can just as easily be performed
by pushing a button on the relevant box?    Somehow, I think not
(eject is nice to have, but not a requirement for anything).

  | One file seems to have moved from /sbin (OBSD) to /usr/bin (NBSD):
  |   mkfifo
  | 
  | Now, that's a bit of a surprise!  In NetBSD, never to be used by a 
  | system script,

Never used by a system script that runs before /usr is going to
be available.   That means, mostly, just the system scripts whose
function is to prepare the system for mounting /usr.  So, no,
I cannot thing of anything for which mkfifo would be needed.

kre