Subject: Re: grep in rescue (was Re: on not shooting yourself in the foot
To: Izumi Tsutsui <firstname.lastname@example.org>
From: George Michaelson <email@example.com>
Date: 03/21/2007 09:18:00
On Tue, 20 Mar 2007 22:10:13 +0900
Izumi Tsutsui <firstname.lastname@example.org> wrote:
> email@example.com wrote:
> > > I also notice grep isn't in /rescue. It was the only element of my
> > > script which wasn't available there. I know this quickly descends
> > > into a bikeshed, but I wondered if grep wasn't perhapsI know this
> > > quickly descends a /rescue-worthy tool?
> > I changed the subject so this wouldn't be forgotten.
> > Anyone have an answer for that?
> IMO, /rescue should contain only tools which are required to recover
> boot disk or base files in /, /lib, and /usr directories
> (except tetris(6)?) and I rarely used grep(1) on such work.
> Personally I prefer bc(1) to calculate disklabel partitions ;-)
I did say "I know this quickly descends into a bikeshed" but I didn't
think it descended *that* quick! :-)
oh. my <foobar> isn't being detected at kernel boot. I wonder why?
boot single user.
dmesg | grep <device>
oh. no grep.
$ ls -l /rescue/ed
-r-xr-xr-x 144 root wheel 4100284 Mar 20 12:29 /rescue/ed
since ed as g/re/p, I begin to think the actual cost of including grep
as an exposed command is uber-low. equally, I suppose we can all hack
scripts out of ed to do this for us.
> We could have static grep in some dir if needed.
um, isn't this going to cost considerably more than /rescue linkage?
(don't get me started on having /rescue/csh, /rescue/sh and /rescue/ksh)