TCC 20 variable expansion bug

[nikbackm]

I was just testing "TCC 20.11.46 x64 Windows 10 [Version 6.3.14393]" and noticed some of my find scripts no longer worked compared to TCC 15.

Simplified reproduction below:

@echo off

set re=(?i-)str
set filename="C:\filename.txt"

echo ffind /e"%re%" %filename%

TCC 20 will print out: ffind /e"(?i-)str" %filename%

TCC 15 will print out: ffind /e"(?i-)str" "C:\filename.txt"

Obviously the latter is what I want. :)

What went wrong with TCC 20? Is it a bug, or am I doing it wrong somehow?

 

[vefatica]

It does look like something is wrong, but here, it's no better with v15.

v:\> type eff.btm
@echo off
ver
set re=(?i-)str
set filename="C:\filename.txt"
echo ffind /e"%re%" %filename%

v:\> eff.btm

TCC  15.01.58   Windows 7 [Version 6.1.7601]
ffind /e"(?i-)str" %filename%

 

[nikbackm]

Interesting.

I use version 15.00.34 x64 of v15 so a little older. Apparently something changed shortly after that then.

The problem seems to be that the parentheses somehow interfere with the parsing/expansion.

Should maybe find some other way to include them in the regular expression for the /E switch of FFIND?

 

[vefatica]

Should maybe find some other way to include them in the regular expression for the /E switch of FFIND?

It goes well beyond FFIND and regular expressions.

v:\> set zz=(a)

v:\> set yy=b

v:\> echo %zz %yy
(a) b

v:\> echo "%zz" %yy  <================?????????????
"(a)" %yy

v:\> echo "(a)" %yy
"(a)" b

 

[nikbackm]

I added a work-around to my script so now it works for me with the newer versions as well.

Previously I used:

....
ffind %ffindargs% /e"%re%" %filenames%

Where the "re" variable was constructed according to the passed parameters and often contained parenthesis. When this was the case the "filenames" variable was not expanded.

The new work-around code is simply:

....
set re="%re%"
ffind %ffindargs% /e%re% %filenames%

This way the "filenames" variable is properly expanded.

Still, would be interesting to know why the old way did not work. Seems correct to me, but I will not pretend to understand all the intricacies of TCC/CMD command line parsing. Quite a lot of edge-cases!

 

[rconn]

The problem is because the leading ( causes the parser to think it's processing a command group. The trailing double quotes don't match up so the parser assumes that everything following the first trailing double quote shouldn't be expanded.

I have a workaround for this syntax in the next build of v21 & beyond. I doubt it will be back-ported to prior versions like v20.

 

[nikbackm]

Thanks for the info, and no need for back-porting to v20. I will upgrade to v21 or newer at some point, and the current work-around is good enough for now.