Command line DO with no closing parenthesis?

May 20, 2008
12,176
133
Syracuse, NY, USA
In many cases, using a one-line DO without a closing parenthesis will give an error.

Code:
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.

Code:
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.

Code:
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?
 
May 30, 2008
238
2
With TCC 20.11.46 x64 I do not see that, always get an error for unclosed parenthesis.
 
May 20, 2008
12,176
133
Syracuse, NY, USA
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.

Code:
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

Super Moderator
Staff member
May 20, 2008
4,689
106
Albuquerque, NM
prospero.unm.edu
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?
 
May 20, 2008
12,176
133
Syracuse, NY, USA
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.

Code:
v:\> do i=1 to 2 ^
More? (
More? echo foo
More? )
foo
foo
 
May 30, 2008
238
2
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

Administrator
Staff member
May 14, 2008
12,557
167
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.
 
May 20, 2008
12,176
133
Syracuse, NY, USA
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

Super Moderator
Staff member
May 20, 2008
4,689
106
Albuquerque, NM
prospero.unm.edu
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?
 

Similar threads