Re: zgrep -<NUM> doesn't work if <NUM> is two digits or greater

[Thomas Bushnell, BSG]

On Mon, Aug 6, 2012 at 3:20 PM, Eric Blake <address@hidden> wrote:

> On 08/06/2012 12:39 PM, Thomas Bushnell, BSG wrote:
> > works.  But:
> >
> >    $ zgrep -10 17 file.txt.gz
> >    gzip: 17.gz: No such file or directory
>
> Yep, the zgrep option parser is busted on 2-digit numbers; it tries to
> separate things into '-1 0' rather than rewriting it to '-C 10' or even
> passing it through unchanged.


But you must remember that gzip _already_ understands '-1' through '-9'
> as independent options.  So which should win?  Should zgrep assume that
> you are asking for option -1 followed by option -0 for use by gzip, or
> that you are asking for option -10 understood by grep?  Or do the
> numeric options of gzip only apply to compression, but zgrep implies
> decompression, therefore we should be assuming grep syntax instead of gzip?
>

I don't understand what you mean. I'm speaking about zgrep and not gzip.

zgrep understands -1, and means by it "include one line of context in the
grep output"; it does *not *mean "use fast compression". And there is no
reason it would; since zgrep only decompresses, there isn't any need for it
to support the -<NUM> options of gzip.

zgrep's manpage says:

SYNOPSIS
       zgrep [ grep_options ] [ -e ] pattern filename...

DESCRIPTION
       Zgrep  invokes grep on compressed or gzipped files.  All options
specified are passed directly to grep.  If no file is specified,
       then the standard input is decompressed if necessary and fed to
grep.  Otherwise the given files are  uncompressed  if  necessary
       and fed to grep.

So I think the answer is already there: *none *of the options are gzip
options, *all *of the options are grep options.

Is the bug that zgrep is using the same parsing code as gzip, then?

Thomas