bug-grep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-grep] [bugs #12210] EGexecute() fails to find matches on (exact &&


From: Claudio Fontana
Subject: [bug-grep] [bugs #12210] EGexecute() fails to find matches on (exact && match_icase)
Date: Fri, 4 Mar 2005 23:15:29 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10

Follow-up Comment #8, bugs #12210 (project grep):

Hello,

> > grep.c::prline()
> 
> The prline() problem where the case-folded match
> instead of the original is
> printed is known.  I advocate getting rid of the
> whole thing in patch #3767
> as it's no longer needed anyways (unless you can
> prove otherwise).

Well, ok we both agree that those should be removed,
and I looked at patch #3767 (got the .c), and it would
work ok if not for the problem I am trying to explain
:)

Try to apply your patch, build, then type:

$ echo Claudio | ./grep -i --color claudio
Claudio

great...but where's the color?

$ Try also:
echo Claudio | ./grep -i -o claudio

[nomatch]

 - Sorry about my name being everywhere :P

This is exactly the point I am making..
your patch SHOULD work, but does not due to a problem
internal to EGexecute when called with exact=1 or one
of the called functions / related state. At least this is what happens on my
box.

I have tried to address the issue among others in a
patch I am preparing.

Note that I did exactly just like you removing the
special (match_icase) treatment, but then observing it
does not work in match_icase cases, I hit my head
against the monitor studying the thing and did NOT
come out with a solution, mainly because I still don't
get the various involved regex internals. Given enough
time, I hope to learn it all.

I looked at another person's patch (cannot remember
anymore, called something like javaed, could have been
unrelated), and noticed he assigned to
patterns[pcount].regexbuf.translate . So I supposed I
could do once and for all at the start of program a 

if (match_icase) 
  build_translation_table(); /* with a for..TOLOWER() */

/* and then when adding a pattern */

if (match_icase) 
patterns[pcount].regexbuf.translate =
icase_trans_table;

It seems to work nicely, however I do not know if
there are issues about wide char strings (I do not
have wide char strings support compiled in, never programmed using them
-still using LANG=C and ASCII7 files-). To
build the translation table I am using TOLOWER macro.

Maybe you could help me by making it work with wc
strings too?

The patch in question is contained in this:

http://cmdftp.sourceforge.net/preview.p1.patch

You could find some variable names changed, however you
should be able to figure out by looking at grepopt.h

Claudio



    _______________________________________________________

This item URL is:

  <http://savannah.gnu.org/bugs/?func=detailitem&item_id=12210>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]