Author Topic: Bug? - Find In Files, Perl, word boundary matches non-boundaries  (Read 6818 times)

aaronla

  • Guest
I believe I've encountered a bug in SlickEdit v13.0.1 Windows, Find In Files under Perl regex syntax with the string "\bCompare\(" also matches "InfixCompare(" etc.

I would expect \b to only match word boundaries.  In the regex expression window, with the sample lines "InfixCompare(test)" and "Other Compare(test)", only the second matches with the regex string "\bCompare\(".  However, given a saved file with the same contents, find in files finds two matches, one for each line. 

It appears that the word boundary \b regular expression behaves differently in function in Find In Files.  Is this a bug?

#aaron

chrisant

  • Senior Community Member
  • Posts: 1413
  • Hero Points: 131
Re: Bug? - Find In Files, Perl, word boundary matches non-boundaries
« Reply #1 on: August 25, 2008, 05:56:27 pm »
Are you sure you're using the same regex type (SlickEdit, Unix, Brief) for both the regex evaluator and the File In Files command?

Lee

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1143
  • Hero Points: 103
Re: Bug? - Find In Files, Perl, word boundary matches non-boundaries
« Reply #2 on: August 25, 2008, 06:19:33 pm »
A quick test using your example shows that it's working for me.  Double-check your settings, and if it's still not working correctly check you can check the output in the Search Results, it will at least confirm that you are using Perl syntax in the initial results line.  And you can also record a macro and we can look at what options are being passed to the find/mffind comands.

aaronla

  • Guest
Re: Bug? - Find In Files, Perl, word boundary matches non-boundaries
« Reply #3 on: August 25, 2008, 07:48:24 pm »
From the Search Results window:

    Find all "\bCompare\(", Match case, Regular expression (Perl), "<Project>", "*"

Search options (quotes delimit the contents of the text box, not quotes appearing in text box)

  Search For: "\bCompare\("
  Look in: "<Project>"
  File types: "*"
  Exclude: ""
  Match Case: checked
  Match whole word: unchecked
  Use: checked
  (drop down): "Regular expression (Perl)"
  Colors: None

Slick edit info:
  SlickEdit Version 13.0.1.0
  OS: Windows Vista or "Longhorn"
  Version: 6.00.6000 
  Memory: 58% Load, 2429MB/4125MB Physical, 389MB/2097MB Virtual
  Installation Directory: C:\Program Files (x86)\SlickEdit 2008\ (non-removable drive,NTFS,xxMB free)
  Hotfixes:
  C:\Users\xx\Documents\My SlickEdit Config\13.0.1\hotfixes\hotfix_se1301_cumulative.zip (Revision: 17)
  C:\Users\xx\Documents\My SlickEdit Config\13.0.1\hotfixes\tmp.zip (Revision: 20)

It appears that slick edit reused the name of the temp file when i downloaded hotfixes last time.  Perhaps related?

#aaron

Lee

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1143
  • Hero Points: 103
Re: Bug? - Find In Files, Perl, word boundary matches non-boundaries
« Reply #4 on: August 25, 2008, 08:17:51 pm »
The options appear correct, and I am unable to reproduce the error with the information you have provided.  What emulation are you using and can you provide the file that is causing the incorrect result?

aaronla

  • Guest
Re: Bug? - Find In Files, Perl, word boundary matches non-boundaries
« Reply #5 on: October 17, 2008, 10:53:57 pm »
I'm starting with the Visual C++ 6 emulation, and then going from there.

It appears that the repro depends on whether the file is _open_ or not.  If i have "this is a test" in a text file, with each word on a separate line, saved as c:\tmp\foo.cpp, and do find in files for \bis\b, i get the result:

    Find all "\bis\b", Match case, Regular expression (Perl), Subfolders, "c:\tmp", "fo*.cpp"
    File c:\tmp\foo.cpp
      2 1:is
    Total found: 1     Matching files: 1     Total files searched: 3

If i close the file, and then re-run the search:


    Find all "\bis\b", Match case, Regular expression (Perl), Subfolders, "c:\tmp", "fo*.cpp"
    File c:\tmp\foo.cpp
      1 3:this
    Total found: 1     Matching files: 1     Total files searched: 3

I get _incorrect_ results.  Can you repro now?  here again is the source file foo.cpp:

    this
    is
    a
    test

Thanks

#aaron