Please, NO. There wasn't an FTP client available for this type of recovery pre-/rescue, there shouldn't be one now.
"This type of recovery" (repairing a system with a trashed /bin) wasn't possible at all pre-/rescue. Had it been possible, /rescue wouldn't be needed.
Bruce M Simpson wrote:
I think David has valid concerns here about feeping creaturism. fetch has a whole load of library dependencies which go with it, making it unsuitable for inclusion in /rescue in the base system.
Fetch requires libfetch (45k). I've not tested, but I expect it adds less than 64k to /rescue.
Scenarios that require /rescue are ones in which /bin and /sbin are unusable, which is almost always going to imply a trashed file in /bin, /sbin, or /lib. Thus, most /rescue scenarios are going to involve locating a good copy of a trashed file to replace a damaged local copy.
I can only think of a few places where that "good copy" can come from: * CDROM: requires a CD-ROM drive, and a suitable CD. * floppy: requires a floppy drive * NFS: requires a local network and an NFS server * An HTTP or FTP server: requires a network connection and 'fetch.'
I don't think we can safely assume that everyone has access to one of the first three options here.
Given the choice between 'vi' and 'fetch,' I'd definitely choose the latter. ('vi' is useful for repairing config files; errors in config files are not generally going to break /bin.)
I don't see fetch as a requirement for diskless clients.
This is a red herring: diskless clients don't need /rescue since any "recovery" necessary can be done on the server. Whether or not diskless clients require fetch has therefore no bearing at all on the question of whether fetch should be in /rescue.
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"