GNU bug report logs -
#37754
wish for grep --and -eX -eY -eZ (X∩Y∩Z intersection, not X∪Y∪Z union)
Previous Next
Full log
Message #8 received at 37754 <at> debbugs.gnu.org (full text, mbox):
On Tue, 15 Oct 2019 12:48:17 +1100
"Trent W. Buck" <trentbuck <at> gmail.com> wrote:
> Package: grep
> Version: 3.3-1
> Severity: wishlist
>
> This bug was originally reported as
> https://bugs.debian.org/940464
>
> Trent W. Buck wrote:
> > (Surely someone has already asked for this, but I can't see where.
> > I may have already reported this myself, and forgotten.
> > If so, sorry!)
> >
> > Right now if you do
> >
> > grep -eX -eY -eZ
> >
> > You'll get lines that match *any of* X, Y, or Z.
> > Quite often I want to search for lines that match *all of* X, Y, and Z ? but in any order.
> > For example,
> >
> > # all 4TB 2.5-inch SATA products
> > grep -Fwi -eSATA -e2TB -e2.5in products.csv
> >
> > Below is a short discussion of the workarounds I know about.
> >
> > Is "grep --and" something that has already been discussed and rejected?
> > I looked through debbugs.gnu.org and the source tarball, but
> > I couldn't find anything about this.
> >
> >
> > PS: grep -v --and would intuitively mean "not all",
> > i.e. "grep -v --and -eX -eY" would return lines matching X *or* Y, but
> > omit lines matching *both* X and Y.
> >
> > PS: I can't decide if "--and" or "--intersection" is a better name.
> > I put both in the bug subject so people searching for either will find this ticket.
> > I think "--all" is probably too confusing.
> >
> >
> >
> > Workaround #1
> > =============
> > I can work around this by listing every possible order, but 1) this
> > scales poorly with the number of patterns; and 2) it can't be used
> > with -F. For example,
> >
> > grep --and -eX -eY -eZ input*.txt # becomes
> >
> > grep -eZ.*Y.*X \
> > -eZ.*X.*Y \
> > -eY.*Z.*X \
> > -eY.*X.*Z \
> > -eX.*Z.*Y \
> > -eX.*Y.*Z \
> > input*.txt
> >
> >
> > Workaround #2
> > =============
> > I can pipe greps together. This is what I currently do.
> > This is more convenient and feels faster than workaround #1, but
> > I suspect the inter-process overhead is significant.
> >
> > If grep implemented this internally, it could zero-copy.
> > Being able to "grep -rnH --and" &c would also be convenient.
> >
> > For example,
> >
> > grep --and -F -eX -eY -eZ input*.txt # becomes
> >
> > cat input*.txt |
> > grep -F -eX |
> > grep -F -eY |
> > grep -F -eZ
>
Although I do not know wheter it is discussed and/or rejected, to add
the function to grep, internal conversion as workaround #1 will be
impremented in grep. However, it scales poorly as you say, and it will
be slower than workaround #2 in many cases.
This bug report was last modified 2 years and 149 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.