On Sun, May 25, 2003 at 09:28:55PM +1000, Geoff Wing wrote:
  | [Also resent through netbsd-bugs]
  | Luke Mewburn <luke@mewburn.net> typed:
  | :  | 	Not sure.  Either rcp needs an option (or env var) to override the
  | :  | 	hardcoded rsh command or the path needs to be changed to /rescue/rsh
  | :  | 	during the rescue tool build process
  | :The former should be achievable with:
  | :	export RCMD_CMD=/rescue/rcmd
  | :That said, /rescue/rcp should be compiled in a manner which does this
  | :automatically for you.
  | 
  | My rcp(1) doesn't mention that I'm supposed to read rcmd(3).  Even
  | my rcmd(1) doesn't mention that.
  | 
  | I've no qualms about doing things that might make my system usable for
  | a time, but I don't expect stumblings blocks to be placed in front of
  | me when trying to revive it.

These "stumbling blocks" are not a deliberate action by us.

You've raised reasonable points that rsh(1) and rcmd(1) (and
environ(7) for that matter) don't have reference to $RCMD_CMD, and
should.  Could you submit a separate PR highlighting this to ask
the documentation crew to rectify this?


  | Even the floppy disks have ftp on them.  Why isn't that part of /rescue ?
  | Why isn't everything that's on the floppy install disks in the /rescue dir?

Because the contents of /rescue was determined from what was in /bin and
/sbin at the time of the switch to making the system fully dynamic, not
what's on the install media floppies on various platforms; this was to
give people at least the functionality they had with a static /bin and
/sbin in the case of a system failure.  Before we switched to a fully
dynamic system, it's possible that you wouldn't have had a functional
ftp then either...

That's not so say that we can't expand the scope of what's in /rescue,
and there are tools in /usr/{bin,sbin,...} that could be added to it.

Luke.