Subject: Re: grep in rescue (was Re: on not shooting yourself in the foot
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
From: George Michaelson <ggm@apnic.net>
List: current-users
Date: 03/21/2007 09:18:00
On Tue, 20 Mar 2007 22:10:13 +0900
Izumi Tsutsui <tsutsui@ceres.dti.ne.jp> wrote:

> reed@reedmedia.net 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)

no worries. 

-G