FSEARCH /T using regular expressions?

[vefatica]

d:\tc34> ffind /t"[Tab" /v d:\tcmd.ini
TCC: premature end of char-class "(?i)[Tab"
TCC: premature end of char-class "(?i)[Tab"
TCC: premature end of char-class "(?i)[Tab"
TCC: premature end of char-class "(?i)[Tab"
TCC: premature end of char-class "(?i)[Tab"
TCC: premature end of char-class "(?i)[Tab"
TCC: premature end of char-class "(?i)[Tab"
TCC: premature end of char-class "(?i)[Tab"
TCC: premature end of char-class "(?i)[Tab"
TCC: premature end of char-class "(?i)[Tab"
TCC: premature end of char-class "(?i)[Tab"
TCC: premature end of char-class "(?i)[Tab"
TCC: premature end of char-class "(?i)[Tab"
TCC: premature end of char-class "(?i)[Tab"
TCC: premature end of char-class "(?i)[Tab"
TCC: premature end of char-class "(?i)[Tab"

Regex-escaping the '[' with '\' doesn't help. Apparently, something is turning '\' into '\\'.

d:\tc34> fsearch /s /t"\[Tab" /v d:\tcmd.ini
TCC: premature end of char-class "(?i)\\[Tab"
TCC: premature end of char-class "(?i)\\[Tab"
TCC: premature end of char-class "(?i)\\[Tab"
TCC: premature end of char-class "(?i)\\[Tab"
TCC: premature end of char-class "(?i)\\[Tab"
TCC: premature end of char-class "(?i)\\[Tab"
TCC: premature end of char-class "(?i)\\[Tab"
TCC: premature end of char-class "(?i)\\[Tab"
TCC: premature end of char-class "(?i)\\[Tab"
TCC: premature end of char-class "(?i)\\[Tab"
TCC: premature end of char-class "(?i)\\[Tab"
TCC: premature end of char-class "(?i)\\[Tab"
TCC: premature end of char-class "(?i)\\[Tab"
TCC: premature end of char-class "(?i)\\[Tab"
TCC: premature end of char-class "(?i)\\[Tab"
TCC: premature end of char-class "(?i)\\[Tab"

 

[rconn]

I'm not sure what you're reporting here - that the error messages are inconsistent between FFIND and FESEARCH?

 

[vefatica]

It's pretty clear that /T is using regular expressions and that the user-entered '\' is getting doubled. It's OK with me if /T uses regular expressions but if TCC is doubling the '\', it shouldn't. '\' is the escape character in regular expressions and doubling it will turn it into a literal backslash in the regular expression. In my example, the '\' was meant to escape the '[' precisely so it wouldn't be the beginning of a char-class. The user can double backslashes if need be

 

[rconn]

You should be using /E, not /T if you're using a regular expression.

 

[vefatica]

I didn't want to use a regex. I first used /t"[Tab" and discovered that TCC was using a regex anyway.

 

[rconn]

Your second example used a regex, and it works if you use /E.

 

[vefatica]

Your second example used a regex, and it works if you use /E.

I know. So what?

More needs to be said about how /T works. It's nothing like FFIND.

 

[Jay Sage]

Vince,

I had the same reaction you did to this problem, but I finally figured it out, I think. Your /T example is not using a regular expression; it is using TCC wildcards. Here's what the help says:

/T"..." Search for the matching text. Supports TCC wildcards (?, *, and [...]).

If you add the /I option ("Used with /T to tell FSEARCH to ignore wildcard characters (*, ?, and [...]).", then the command works as expected. What's new in FSEARCH is the ability to use TCC's extended wildcards in the text string. That endows a left square bracket with a special meaning.

I did think that escaping the left square bracket would force it to be interpreted as a text character, but that does not work.

>fsearch /l /v /t"^[t" tmp0:
TCC: premature end of char-class "(?i)[t"

As suggested in the help for "Wildcards and Regular Expressions", you can overcome the problem by actually creating a character set with the left bracket character. The help examples show how to use that trick for file names with semicolons.

>fsearch /l /v /t"[[]t" tmp0:

---- tmp0:
[3] string [tab

 

[vefatica]

I think. Your /T example is not using a regular expression; it is using TCC wildcards

The error message is coming from Oniguruma. What does "(?i)" have to do with wildcards?

v:\> fsearch /s /t"[Tab" /v d:\tcmd.ini
TCC: premature end of char-class "(?i)[Tab"

 

[vefatica]

FSEARCH's /T seems to be doing what FFIND's /TE does. Thanks for mentioning /I. IMHO, /T and /TE would be better (for consistency with FFIND).

 

[rconn]

/I is not the same as /TE. /I tells FSEARCH (or FFIND) not to treat the '[' as a wildcard character. /TE converts the search string to a regex string.

[D:\TakeCommand34\x64\Debug]fsearch /s /i /t"[Tab" /v tcmd.ini

---- D:\TakeCommand34\x64\Debug\TCMD.INI
[Tab1]

Matching lines: 1        Matching files: 1        Total files searched: 1

 

[vefatica]

Yes, that's how I understand it. Without /I, FSEARCH's /T is like FFIND's /TE. With /I, FSEARCH's /T is like FFIND's /TE.

 

[Jay Sage]

So is the /T option really (without being asked to) switching to regular-expression mode, as if /T had been /E? Or are TCC extended wildcards being handled by the regular-expression processor?

 

[rconn]

FSEARCH is converting the /T search string to a regex (because it's much, much faster).