Command line DO with no closing parenthesis?

[vefatica]

In many cases, using a one-line DO without a closing parenthesis will give an error.

v:\> do i=1 to 2 ( echo %@random[0,1]
Usage : DO [n | FOREVER]

If I replace @random (above) with the plugin @mrand, I get no error message.

v:\> do i=1 to 2 ( echo %@mrand[0,1]

v:\>

There's nothing special about @random and @mrand. Any built-in variable function used in place of @random will produce the error message. And any plugin variable function will suppress the error message. The same seems true of internal _VARIABLE vs. plugin _VARIABLE.

v:\> do i=1 to 2 ( echo %_time
Usage : DO [n | FOREVER]

v:\> do i=1 to 2 ( echo %_npids

v:\>

Why do they behave differently?

 

[nikbackm]

With TCC 20.11.46 x64 I do not see that, always get an error for unclosed parenthesis.

 

[vefatica]

With TCC 20.11.46 x64 I do not see that, always get an error for unclosed parenthesis.

Interesting! Do you have plugins to test with? I see the same with v20 as I do with v26.

g:\tc20> ver

TCC  20.11.46   Windows 7 [Version 6.1.7601]

g:\tc20> do i=1 to 2 ( echo %@len[xxx]
Usage : DO [n | FOREVER]

g:\tc20> echo %_npids
41

g:\tc20> do i=1 to 2 ( echo %_npids

g:\tc20>

And, at least on Win7/32 the behavior goes back to v12, the first version with the command line DO.

 

[Charles Dye]

I see different behaviors for internal vs. plugin functions and variables. But... is either behavior really correct? Shouldn't TCC be prompting for a continuation line?

 

[vefatica]

I see different behaviors for internal vs. plugin functions and variables. But... is either behavior really correct? Shouldn't TCC be prompting for a continuation line?

I never thought that would work for the command line DO. The help says

To use them in aliases or at the prompt, you need to define the DO on a single line, and enclose the body of the DO loop in a command group following the DO expression.

I never use '(' in that way and the only place I'm sure it works in with the FOR command and that's only because I've seen many examples of it here.

You can force multi-line input with an escaped newline before the '('. After that it behaves as expected. But I imagine that at execute time, it is all on one line.

v:\> do i=1 to 2 ^
More? (
More? echo foo
More? )
foo
foo

 

[nikbackm]

Interesting! Do you have plugins to test with? I see the same with v20 as I do with v26.

Sorry, I missed that it only happens with plugin functions and variables.
Don't have any plugins myself.

 

[rconn]

Both formats are error-ing out and calling the Usage() function. The plugin handler has to remove the internal command name (so that plugin errors won't show the wrong command), so the usage function gets an empty string for the name, and consequently doesn't display any usage info.

 

[vefatica]

I don't understand. It's DO that's error-ing out, right? Is it then calling Usage() in some/all plugins (before the internal Usage() function)? All my Usage() functions return 1 if they handle the call (i.e., recognize the name and print a usage message) and 0 if they don't. [Have I got it backwards?] I don't see the need to remove the internal command name.

 

[Charles Dye]

Both formats are error-ing out and calling the Usage() function. The plugin handler has to remove the internal command name (so that plugin errors won't show the wrong command), so the usage function gets an empty string for the name, and consequently doesn't display any usage info.

But... the issue happens with plugin variables and functions. Not plugin commands. Usage() is only called for commands, right?

 

[rconn]

DO is calling variable expansion, which is calling the plugin handler, which is removing the internal command name. Then it calls Usage() because you didn't have a trailing ).