Question regarding search (ALT+F7 "Find Files")...

[Valentino]

Regexp... Как много в этом слове... <beware! strong salivation here>

I agree with JackFoo that there must be a parameter for memory buffer (if I understood correct, like sliding buffer in Lister). Just in case... Who knows what may become necessary in the future... Some extraordinary task...

[ghisler(Author)]

And other - will you implement regexp searches in the same thread - or other?

Curently the search function isn't multi-threaded, sorry. Can you give me an example of a regular expression which hangs?

[ado]

Would a per line search (limited to, say, 1k lines) be sufficient?

Christian, Please, 10k at least. A found a lot of XML config. files without "NewLine"....

...and personaly I would prefer if you can extend line size in internal Listener to ~10k too

ado

[oblomov]

What library are you using (or have you created your own.. icon_eek.gif ) ?

I'm using this one:

http://anso.virtualave.net/

The advantage is that it's free also for commercial use, so no problem to add to my software. I also had no problems to build it with Delphi 2.0, and it seems to be fast too.

Is there a particular reason why you didn't use Perl Compatible Regular Expressions (www.pcre.org)?

Btw, what do you think, should regular expressions be case sensitive or insensitive by default? I plan to make it configurable, but what should be the default? I ask because file names are case-insensitive on Windows, but regular expressions come from Unix and are therefore usually case-sensitive...

I would say case insensitive by default

Currently my problem is how to support regex for text searches. A user could define an expression which matches a whole 2 GB file - too large to hold in memory. Any ideas? Would a per line search (limited to, say, 1k lines) be sufficient? And how to handle binary files?

Maybe a buffered search instead of something line-based? A (configurable in the .ini) "window" that scrolls on the file, preventing regexes from being too hungry? OTOH, badly-written regexes are supposed to misbehave ... if the user doesn't know what he's doing, he shouldn't be using regexes in the first place If he does and the computer goes to sleep for overstress .... maybe just provide a "cancel" (or "skip file") button?

[ghisler(Author)]

Is there a particular reason why you didn't use Perl Compatible Regular Expressions (www.pcre.org)?

Yes, several!
- PCRE is written in C/C++, so I would have to use it in an external DLL, not compiled into the EXE
- PCRE is huge, so I could no longer deliver TC on a single floppy
- the library which I'm using now already supports a large set of regular expressions. Have you tried the precompiled sample?

[oblomov]

the library which I'm using now already supports a large set of regular expressions. Have you tried the precompiled sample?

Uh, no. Which precompiled sample?

[soreno]

Get it here (!):
http://anso.virtualave.net/regexpr.zip

[gromit]

Btw, what do you think, should regular expressions be case sensitive or insensitive by default? I plan to make it configurable, but what should be the default? I ask because file names are case-insensitive on Windows, but regular expressions come from Unix and are therefore usually case-sensitive...

I feel it should be case sensitive, so as not to detract from the power regEx offers.

[Valentino]

2gromit
Christian means (if I understood correctly) "by default". So this is configurable. No power detraction.

[ghisler(Author)]

Yes, it's configurable. And I will probably make it case insensitive by default.

[gromit]

Yes, it's configurable. And I will probably make it case insensitive by default.

That'll be great

I've seen what can be achieved using RegExp in my Newsreader (Forté Agent) and it would be an excellent addition to TC.

[ghisler(Author)]

An update about regular expressions support: I have now added regular expression searches both to the search function and to Lister.

As a compromise, regular expressions are applied to the searched file line by line, so they cannot reach over multiple lines. Also there is a maximum line length of 4k. These are the same limitations as in the pcregrep tool (a sample program comming with the PCRE library recommended by oblomov above).

Btw, I checked PCRE, and it doesn't have any special support for files either, so I will continue to use my current library. It only increases the totalcmd.exe size by 8k when packed with UPX or ASPack!

[sergeycentral]

First of all, thanks for the regular expression searching option!! I have long been awating this also.

I have a question about how it will be presented. For instance, when selecting a group of files, could you have a button ("RegExp" ) next to "Define" lets say, that would show the different expressions available, eliminating the stress of memorizing them?....or using:

Funduc's Search and Replace Regular Expression Wizard

Sergey

[ghisler(Author)]

Currently on select/unselect files, you have to begin a regular expression with the character < (this is similar to defined searches, where you use <). In the "Find files" dialog, both < and a checkbox labeled "RegEx" work.

[oblomov]

An update about regular expressions support: I have now added regular expression searches both to the search function and to Lister.

Cool

As a compromise, regular expressions are applied to the searched file line by line, so they cannot reach over multiple lines. Also there is a maximum line length of 4k.

I don't know if 4K will suffice (but I guess that if it won't, it'll get expanded in the next next version ). About searching line-by-line: a (complex) way to handle the thing could be to see if the regexp needs a multi-line search (has things like \r or \n or something like that) and only enable multi-line in that case. Not sure about it should work, though.