findstr doesn't always find

  • Thread starter Thread starter jkwold
  • Start date Start date
J

jkwold

I'm converting 300+ MSVC6 projects to VS2005 and fighting with .def
files (hooray for APIs and customers !) and the changes in mangled
names (particularly for CString :-) -- I've been depending on findstr
for much of the analysis, and just today found a case where the search
string wasn't always found. The string in question is:

?Initialize@CYpsBrowseIncludeDataDlg@@QAEXW4BrowseType@1@AAV?
$CStringT@GV?$StrTraitMFC_DLL@GV?$ChTraitsCRT@G@ATL@@

Note that that's not a full mangled name; I haven't found the actual
limit, but have taken to truncating strings longer than 115 chars as
findstr fails somewhere beyond that -- trivia. I'm launching findstr
as follows:

findstr /g:SR_req'd *def

The lengthy mangled name is one of 100 or so in the file SR_req'd (the
contents of which, incidentally, are sorted) -- it's about 40 lines
into that file (a collection of mangled names, all truncated at column
115). The subdir in which I run findstr has 357 *.def files, one of
which does contain that string.

If I truncate SR_req'd down to a mere 44 lines, then that mangled
name is found.

In the 100+ line /g:file case, numerous other matches are encountered
(it's not like nothing is found), including items both before and
after the not-found line -- I've not yet found rhyme or reason to what
is found and what is not.

I've got cygwin installed, so I'll see how its grep holds up.

Thoughts ?
Jon
 
jkwold said:
I'm converting 300+ MSVC6 projects to VS2005 and fighting with .def
files (hooray for APIs and customers !) and the changes in mangled
names (particularly for CString :-) -- I've been depending on findstr
for much of the analysis, and just today found a case where the search
string wasn't always found. The string in question is:

?Initialize@CYpsBrowseIncludeDataDlg@@QAEXW4BrowseType@1@AAV?
$CStringT@GV?$StrTraitMFC_DLL@GV?$ChTraitsCRT@G@ATL@@
....
Thoughts ?
Click to expand...

Strange, AFAIK findstr uses regex mode by default. Several $ signs to
anchor at line end aren't valid.
Did you try with /L and if necessary /I switches ?

HTH
Matthias
 
Yes, sorry -- forgot to mention that -- /L makes no difference, and I
skipped /I because I want the case-sensitive matching.

Jon
 
cygwin's grep gave the proper results once I ensured that all 0x0d ==
CR were stripped from the relevant files -- as a bonus said grep
properly handled search strings longer than 115+ chars. Example:

grep -F -f SR_req\'d *def

Jon
 
jkwold said:
cygwin's grep gave the proper results once I ensured that all 0x0d ==
CR were stripped from the relevant files -- as a bonus said grep
properly handled search strings longer than 115+ chars. Example:

grep -F -f SR_req\'d *def

Jon
Click to expand...

This doesn't answer you question directly but Perl is practically
designed for such problems -- in many cases these changes become
litterally one line programs.

ActivePerl (.com) for Win32 is excellent.
 
I'm converting 300+ MSVC6 projects to VS2005 and fighting with .def
files (hooray for APIs and customers !) and the changes in mangled
names (particularly for CString :-) -- I've been depending on findstr
for much of the analysis, and just today found a case where the search
string wasn't always found. The string in question is:

?Initialize@CYpsBrowseIncludeDataDlg@@QAEXW4BrowseType@1@AAV?
$CStringT@GV?$StrTraitMFC_DLL@GV?$ChTraitsCRT@G@ATL@@

Note that that's not a full mangled name; I haven't found the actual
limit, but have taken to truncating strings longer than 115 chars as
findstr fails somewhere beyond that -- trivia. I'm launching findstr
as follows:

findstr /g:SR_req'd *def
Click to expand...

JFTR find has a larger buffer (of 1025 characters) than findstr, but is not
as capable, obviously.
 
Back
Top