Parsing error!

[vefatica]

I expected TCC to handle this easily. But ...

v:\> set z=2

v:\> for /l %i in (1,1,%@eval[(%z + 4) / 2]) echo %i
TCC: Syntax error "@eval[(%z + 4"

 

[vefatica]

I expected TCC to handle this easily. But ...

v:\> set z=2

v:\> for /l %i in (1,1,%@eval[(%z + 4) / 2]) echo %i
TCC: Syntax error "@eval[(%z + 4"

Why didn't I get that post in the mail?

 

[Steve Fabian]

vefatica wrote:
| ---Quote (Originally by vefatica)---
|| I expected TCC to handle this easily. But ...
||
||
|| Code:
|| ---------
|| v:\> set z=2
||
|| v:\> for /l %i in (1,1,%@eval[(%z + 4) / 2]) echo %i
|| TCC: Syntax error "@eval[(%z + 4"
|| ---------
| ---End Quote---

Verified here in all versions going back to 6.01.245U. I suspect the parser
looks at the brackets surrounding the function parameters as a
character-selection wildcard, in which role it is, of course, wrong.

| Why didn't I get that post in the mail?

I did not get it, either! So many of my emailed posts to
tc_suggestion[email protected] were never returned that I started sending them to
this NG (which may be useless to do, as Rex reported that he ignores this NG
when looking for suggestions). I think there is a serious flaw in at least
one of the mechanisms which post email messages into the browsable database,
and which email new posts. Another issue is that for those of us whose
registered name in the browser is not representable in ASCII (e.g. Péter
Köves), the non-ASCII letters are just snuffed out by the "remailer", and
e.g. my name shows up as Fbin. I am CC*ing myself on this message, to see
whether or not this last issue is due to how Outlook Express handles my
incoming mail.
--
Steve Fábián

 

[vefatica]

On Sat, 19 Dec 2009 07:07:20 -0600, Steve Fábián <> wrote:

|Verified here in all versions going back to 6.01.245U. I suspect the parser
|looks at the brackets surrounding the function parameters as a
|character-selection wildcard, in which role it is, of course, wrong.

No, functions are fine:

v:\> for /l %i in (1,1,%@eval[1+2]) echo %i
1
2
3

Parens inside of functions are not. I figured they'd be protexted.

v:\> for /l %i in (0,1,%@len[%z]) echo %i
0
1
2

v:\> for /l %i in (0,1,%@len[a(bc)d]) echo %i
TCC: Syntax error "@len[a(bc"
--
- Vince

 

[rconn]

> vefatica wrote:
> | ---Quote (Originally by vefatica)---
> || I expected TCC to handle this easily. But ...
> ||
> ||
> || Code:
> || ---------
> || v:\> set z=2
> ||
> || v:\> for /l %i in (1,1,%@eval[(%z + 4) / 2]) echo %i
> || TCC: Syntax error "@eval[(%z + 4"
> || ---------
> | ---End Quote---
>
> Verified here in all versions going back to 6.01.245U. I suspect the
> parser
> looks at the brackets surrounding the function parameters as a
> character-selection wildcard, in which role it is, of course, wrong.

No -- it's seeing the close paren as the end of the FOR argument list. FOR
is not expecting (or supporting) nested parentheses.

 

[Charles Dye]

I expected TCC to handle this easily. But ...

v:\> set z=2
 
v:\> for /l %i in (1,1,%@eval[(%z + 4) / 2]) echo %i
TCC: Syntax error "@eval[(%z + 4"

You can escape the close paren that's confusing FOR:

for /l %i in (1,1,%@eval[(%z + 4 %=) / 2]) echo %i

That said, it might be better to just split it into two commands.

 

[Steve Fabian]

rconn wrote:
| No -- it's seeing the close paren as the end of the FOR argument
| list. FOR is not expecting (or supporting) nested parentheses.

Given that the current directory contains subdirectory ab(c), I observed
that
for %x in ( ab(c)\* ) echo %x
fails, but
for %x in ( "ab(c)\*" ) echo %x
works. However, neither tab completion nor the function %@quote[ab(c)\*]
adds the quotation marks to allow the FOR command to work. As much as I
shudder about using such directory names, people do use them. IMHO any file
name which gives the parser problems unless quoted should be quoted by both
tab completion and @QUOTE.

Additional suggestion: a new editing keystroke to emulate @QUOTE, analogous
to the keystroke which converts LFN to SFN.
--
Steve

 

[vefatica]

On Sat, 19 Dec 2009 10:33:10 -0600, Charles Dye <> wrote:

|You can escape the close paren that's confusing FOR:
|
|
|Code:
|---------
|for /l %i in (1,1,%@eval[(%z + 4 %=) / 2]) echo %i
|---------
|That said, it might be better to just split it into two commands.

Maybe so for @EVAL, but in other functions, it will give an incorrect result.

v:\> for /l %i in (0,1,%@len[a(bc)d]) echo %i
TCC: Syntax error "@len[a(bc"

v:\> set z=a(bc)d

v:\> for /l %i in (0,1,%@len[%z]) echo %i
0
1
2
3
4
5
6

v:\> for /l %i in (0,1,%@len[a(bc^)d]) echo %i
0
1
2
3
4
5
6
7
--
- Vince

 

[vefatica]

On Sat, 19 Dec 2009 11:04:50 -0600, Steve Fábián <> wrote:

|but
| for %x in ( "ab(c)\*" ) echo %x
|works.

I'm very surprised that quotes protect the paren while being inside a function
doesn't.

Suggestion for the next version: command line DO
--
- Vince

 

[rconn]

On Sat, 19 Dec 2009 11:04:50 -0600, Steve Fábián <> wrote:

|but
| for %x in ( "ab(c)\*" ) echo %x
|works.

I'm very surprised that quotes protect the paren while being inside a function doesn't.

- Vince

Since the FOR argument processing and the variable function expansion are about 50,000 lines of code apart, it's not too surprising to me!

This would require a separate parser just for FOR to preprocess the argument list in the .0000001% of cases where somebody wants to use a variable function with embedded parentheses. (God forbid that the user would decide to use unmatched parentheses...)