Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

ffind /e hangs

Jun
768
6
The command

ffind /b /m /e"foobar" PlayerList13.htm

appears to hang when run on the attached file. CPU is high. I kill it after a few minutes. I have several other files with the same problem. The files are all large: over 10 megabytes. TCC 25.00.26 x64 Windows 10 [Version 10.0.18363.535].
 

Attachments

  • PlayerList13.7z
    1.1 MB · Views: 267
The problem is the length of your lines (>8Mb for the first line). When the buffer wraps (at 8Mb), FFIND is trying to go back to the beginning of the current line and continue the comparison from there. Prior to build 26, FFIND would discard the beginning of the line and read the remainder of the line into the buffer and restart the comparison (thus potentially failing to match the current line, particularly if you're using anchors).

In build 26, because of your line length FFIND is re-reading everything. I can put a check in to build 27 to tell it not to rewind repeatedly to the beginning, but you're going to be back to potentially failing to return valid matches.
 
Is there a better way to do this? The files are the output of test scripts. Since browsers don't care about lines, there is only one line in the file. I've been using ffind to look for strings that would indicate that there were errors in the generation of the pages.
 
Just as idea for workaround:

You could view and save it (should be surely possible to make that with related tools on command line too) through a "html formatter", like this:

(html view from my integrated Total Commander lister as example) ...
html-formatted1.png


After it's possible to save it in exactly this style (WITH linefeeds) and it should no more be a problem then of course ...

Regards.
 
Is there a better way to do this? The files are the output of test scripts. Since browsers don't care about lines, there is only one line in the file. I've been using ffind to look for strings that would indicate that there were errors in the generation of the pages.

If you're not actually specifying regular expressions, you could use /T"...", which is character-oriented and doesn't care about lines.
 

Similar threads

Back
Top