On Wed, Oct 03, 2007 at 07:23:44PM -0700, David O'Brien wrote: > > > > Yar Tikhiy wrote: > > > > >I've had to use /rescue recently and felt lack of a few basic tools > > > > >in it, namely pgrep(1), head(1), tail(1), tee(1), and a text filter, > > > > >e.g., sed(1). Well, in fact most functionality of pgrep(1), head(1), > > > > >tail(1), and even tee(1) can be emulated if one has sed(1), but the > > > > >tools are so tiny and convenient that it's a pity not to have them > > > > >all handy during hard times. > > I also don't see the need for pgrep - I think needing that says your > system is running multiuser pretty well.
First of all, I'd like to point out that /rescue doesn't need to be as minimal as /stand used to. Now, /rescue is a compact yet versatile set of essential tools that can help in any difficult situation when /*bin:/usr/*bin are unusable for some reason, not only in restoring a broken system while in single-user mode. A skillful admin needs a rather limited number of tools, but some of them still are missing from /rescue. As for pgrep+pkill, it can come handy if one has screwed up his live system and wants to recover it without dropping the system to single-user. A valid objection to this point is that pgrep's job can be done with a combination of ps(1) and sed(1), so it's just a matter of convenience. The price for it in terms of disk space is next to nothing, and there are quite useless space hogs in /rescue already (see below on /rescue/vi.) > Also head and tail - why not just add 'more' as that would give more > functionality if you're trying to read a file in /etc to fix something. I won't speak for everyone, but I really like to use fancy shell commands, particularly during hard times: loops, pipelines, etc. So I don't have to enter many commands for a single task or browse through voluminous output for relevant parts. And it's hard to use pipelines w/o basic filters. Again, head(1) and tail(1) can be substituted by sed(1), but my fingers are just used to type "head" or "tail" in certain cases. I suspect that I'm not the only one of this kind out there. As for more(1), there is a reason not to include it in /rescue now, besides its rather large size. Namely it uses ncurses and thus depends on /etc/termcap to work well; but in a really tough case when you can mount only /, /etc/termcap is unavailable because it's a symlink to under /usr. This problem plagues /rescue/vi already (see PR bin/80256.) I think we should postpone adding more(1) to /rescue to after the problem has been fixed. And, of course, more(1) is no substitute for head(1) or tail(1) when it comes to pipelines. > > > > >In addition, there are chflags and chmod in /rescue, but there's > > > > >no chown in it, so the toolset is a bit incomplete. > > I don't see the purpose of chown - if you have to fall back to /rescue > you're user 'root' - and you're trying to fix enough so you can use > standard /*lib & /*bin > > chflags is needed so you can overwrite a file and chmod is needed so you > can "chmod +x" something - those needs are clear. > > Please don't pestimize the build - unless there is a clear benefit. Having /rescue/chown is just a matter of completeness of the ch* subset of /rescue tools because chown's job can't be done by any other stock tools. If /rescue is complete enough, one can find more applications for it. E.g., the loader, a kernel, and /rescue are enough to run single-user and do basic things. (Note that there is /rescue/init.) Of course, what I've just told is my own view of /rescue's role, but it seems to be supported by some other folks. Thank you for your comments! I think this discussion can let us understand better what we need from /rescue. -- Yar _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
