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

[Garrett D'Amore]

I agree that fork/exec is unfortunate, and if we had libs already in the
tree that would be nicer.  But I would prefer not to create a dependency
upon other consolidations if that doesn't already exist.  (Specifically
I don't know of any consumers of bzip2.  But that might be ignorance on
my part.)

In any event, this is functionality we don't even *have* today, so
worrying too much about it being a little bit slower seems like putting
cart before the horse.

	- Garrett

On Fri, 2011-05-06 at 09:59 -0400, Kurt Lidl wrote:
> On Fri, 2011-05-06 at 01:17 -0400, Gordon Ross wrote:
>  > On Fri, May 6, 2011 at 12:04 AM, Garrett D'Amore <garrett at 
> nexenta.com> wrote:
>  > > I have very mixed feelings about introducing these dependencies.  But
>  > > perhaps its time to consider bring these libraries into ON?
>  > >
>  > >        - Garrett
>  > >
>  >
>  > Or it could just fork off a "gzip -dc" (or whatever) when it needs to
>  > decompress something.  I took a stab at that (diff attached).
>  > I did not use popen due to concerns about passing file names
>  > with nasty characters to the shell...
>  >
>  > Gordon
> 
> 
> I like this *much* better.
> 
>      - Garrett
> 
> Forking off a copy of 'gzip -dc', and then having to copy all the compressed
> data through a pipe to gzip, and then having to copy all the uncompressed
> data back through the pipe to grep is slow.
> 
> Yes, I know, it's "common" to do this, but it really stinks, 
> performance-wise.
> Integrating direct usage of the libgz (or libz or libbz or liblzma when 
> the time
> comes) is a huge performance win.
> 
> -Kurt
> 
> (my apologies in advance for the badly formatted response text)
> 
> _______________________________________________
> Developer mailing list
> Developer at lists.illumos.org
> http://lists.illumos.org/m/listinfo/developer