[illumos-Developer] grep -Z etc? (decompress! was: webrev: 650 grep support for -q ...)

[Yuri Pankov]

On Fri, May 06, 2011 at 12:53:27PM -0400, Gordon Ross wrote:
> On Thu, May 5, 2011 at 11:53 PM, Albert Lee <trisk at opensolaris.org> wrote:
> > On Thu, May 5, 2011 at 10:52 PM, Yuri Pankov <yuri.pankov at gmail.com> wrote:
> >> On Thu, May 05, 2011 at 10:21:09PM -0400, Gordon Ross wrote:
> >>> I have mixed feelings about seeing uncompress support in grep.
> [...]
> Yuri:
> >> Think of archives as just another type of file. grep's purpose is to
> >> match lines in files (of different kind) and it does just that - using
> >> those libraries to look inside compressed files. It is especially useful
> >> when doing recursive grep. Just how I see it, anyway.
> >>
> Albert:
> > The motivation here is that grep's design, and the design of Unix
> > tools that traverse directory trees in general, is not sufficiently
> > flexible to implement this with a filter.
> 
> So, that's a fair point.  One might wish for a "search" tool that can
> "look inside compressed files" and the like.  I get that.  But is that
> program grep?  Where do you stop with adding advanced search
> features to grep?  Should it's FTW be able to expand compressed
> tar files and traverse within those too?  (why not?:)
> 
> I'm a little uncomfortable with trying to make grep into that larger
> "advanced search" tool.  I think I'd prefer a separate "tree walk"
> tool that could run grep on a series of files, some of which might
> be burried inside *.tar.gz files or whatever...
> 
> >>> Note that these options cause grep to drag in
> >>> libzlib and libbz2 for the decompress support.
> 
> Which maybe is not so bad, perhaps those should be in the
> illumos gate anyway (to satisfiy other dependencies).
> 
> But even if libz,libbz were there, I like the separability
> and extensibility of (for example) letting the user specify
> some program for grep to run to "expand" files...
> (maybe a much smarter program, that can figure  out
> what kind of file it is, etc.)  Not now, but maybe later.

This way it would be easier to just use XPG4 sed.. no reason in this
import then.


Yuri