code review 6162045: csearch: add -w to allow searching for 'whole words'

csearch: add -w to allow searching for 'whole words'

This patch adds '-w', similar to grep/ack, which puts word boundary
markers ('\b') the start and end of the pattern, if needed.

Fixes issue 13.

[dgryski, 2012-05-02 20:42:01]

Hello rsc@golang.org,

I'd like you to review this change to
https://code.google.com/p/codesearch

[rsc, 2012-06-03 04:57:40]

I'm not sure how I missed this one.  Found it cleaning up my code review
dashboard.

http://codereview.appspot.com/6162045/diff/5001/cmd/csearch/csearch.go
File cmd/csearch/csearch.go (right):

http://codereview.appspot.com/6162045/diff/5001/cmd/csearch/csearch.go#newcode87
cmd/csearch/csearch.go:87: if isWordByte(pat[0]) {
This can't be right. It handles "(a)" and "a" differently. I think it's supposed
to be \b+pat+\b but I'm not really sure.

[dgryski, 2012-06-04 14:10:45]

On Sun, Jun 3, 2012 at 6:57 AM,  <rsc@golang.org> wrote:
> I'm not sure how I missed this one.  Found it cleaning up my code review
> dashboard.
>
>
>
> http://codereview.appspot.com/6162045/diff/5001/cmd/csearch/csearch.go
> File cmd/csearch/csearch.go (right):
>
>
http://codereview.appspot.com/6162045/diff/5001/cmd/csearch/csearch.go#newcode87
> cmd/csearch/csearch.go:87: if isWordByte(pat[0]) {
> This can't be right. It handles "(a)" and "a" differently. I think it's
> supposed to be \b+pat+\b but I'm not really sure.
>
> http://codereview.appspot.com/6162045/

   Hmm.. good point re: ()'s.  This actually brings up a number of
other issues with _any_ "complex" regular expression and I think the
general solution in that case is hard.  Having \b+pat+\b was my first
attempt, but that ends up being wrong (or at least un-expected
behaviour) in the case where pat already starts or ends with a
non-word character, hence the need for the test.

   I think I might abandon this one since it only ends up being
correct in a small number of cases.

   Damian

[rsc, 2012-06-04 14:41:17]

How does GNU grep implement -w? I always thought it was \b+pat+\b.

Russ

[dgryski, 2012-06-04 15:08:24]

On Mon, Jun 4, 2012 at 4:40 PM, Russ Cox <rsc@golang.org> wrote:
> How does GNU grep implement -w? I always thought it was \b+pat+\b.

   It looks like the the PCRE engine uses \b(+pat+)\b , the other
engines do their own magic.  I'm going to re-investigate the case I
thought was failing and look into this again.

   Damian

[dgryski, 2012-06-05 21:00:31]

On Mon, Jun 4, 2012 at 5:08 PM, Damian Gryski <dgryski@gmail.com> wrote:
> On Mon, Jun 4, 2012 at 4:40 PM, Russ Cox <rsc@golang.org> wrote:
>> How does GNU grep implement -w? I always thought it was \b+pat+\b.
>
>   It looks like the the PCRE engine uses \b(+pat+)\b , the other
> engines do their own magic.  I'm going to re-investigate the case I
> thought was failing and look into this again.

Ok, so here's the failing case:
I've indexed the Go source tree.
laptop$ csearch '<rsc@golang.org>'
/tmp/go/CONTRIBUTORS:Russ Cox <rsc@golang.org>

As expected, we find your email address in the CONTRIBUTORS file.

Now, if we bracket the pattern with \b, we no longer find any matches.

laptop$ csearch '\b<rsc@golang.org>\b'
laptop$

:(

However, if we remove one of the <'s
laptop$ csearch '\brsc@golang.org>'
/tmp/go/CONTRIBUTORS:Russ Cox <rsc@golang.org>

Interestingly enough, the grep PCRE engine (which also uses the
"\b+pat+\b") has exactly this failure, while ack, regular grep, egrep,
and fgrep all find the one-line match.

So, this to me says that using -w with patterns that begin or end with
a non-word character fails, and trying to figure out if the pattern
begins or ends with a non-word character requires actually parsing the
regex and inspecting the state machine and adding \b before all the
characters that aren't a word character.  Doesn't seem worth it for
this shortcut.

Damian

[dgryski, 2012-06-06 20:34:38]

*** Abandoned ***