Command grouping and GOTO label

[John Posner]

Consider this batch program, stored in "test.btm":

@echo off

if "%1" == "" goto helplabel

if "%1" == "help" (
:helplabel
echo this
echo is
echo helpful
goto end
)

:end


With CMD.EXE, both "test" and "test help" produce the same 3-line output. With TC11 (TCC 11.00.44), "test" produces the 3 lines, but "test help" produces no output.

It looks like TC11 doesn't like the occurrence of a label within a command group. There's no mention of this in the "Command Grouping" documentation. In the GOTO command description, there's a discussion of "to avoid errors in the processing of nested statements", but there's no specific mention of command grouping.

Is this a doc omission?

Notes:

* Removing the "goto end" statement and the :end label produces an error: Unknown command ")"

* I realize that it would be better to implement this using GOSUB. This is code written by someone else and targeted at CMD.EXE, which I'm executing under TC11.

Tx,
John

 

[Charles Dye]

l
if "%1" == "help" (
:helplabel
echo this
echo is
echo helpful
goto end
)

Remember that a command group is a single line, so that works out to be the same as:

if "%1" == "help" :helplabel echo this echo is echo helpful goto end

If the first argument is help, then do nothing....

 

[John Posner]

Remember that a command group is a single line, so that works out to be the same as:

if "%1" == "help" :helplabel echo this echo is echo helpful goto end

If the first argument is help, then do nothing....

Thanks, Charles, but I'm not convinced. :) Your explanation doesn't account for the error I got when removing the "goto end" statement. And it doesn't explain the behavior of this script:

if "%1" == "help" (
echo MARK 1
echo MARK 2
:foobar
echo MARK 3
)

Script invocation:

> [B]test2 help[/B]
MARK 1
MARK 2

>

It seems to me that the presence of the label inside the command group somehow "breaks the group". That would explain why removing the "goto end" statement caused an error: the script thought it was no longer inside a command group, but then it encountered the closing parenthesis, and so generated the error ... Unknown command ")"

 

[Charles Dye]

It seems to me that the presence of the label inside the command group somehow "breaks the group".

Precisely! All the lines after the label wind up on the same logical line, therefore part of the label and ignored.

I don't really know what would be the "correct" way to handle such a peculiar construct. Perhaps an immediate error message when the parser encounters a label inside a command group...? Or maybe just ignore the label altogether.

I can't speak for Rex, but strongly suspect that mimicking CMD.EXE's behavior in the first situation (jumping into the middle of a command group) would not be feasible without a complete rewrite of the parser.

 

[vefatica]

On Tue, 23 Mar 2010 19:00:35 -0400, Charles Dye <> wrote:

|---Quote (Originally by John Posner)---
|It seems to me that the presence of the label inside the command group somehow "breaks the group".
|---End Quote---

It doesn't answer the questions, especially the CMD compatibility one, but using
the much more powerful IFF/ENDIFF would, I believe, make all the problems go
away. I've never needed CMD compatibility and wouldn't mind if IF simply went
away.
--
- Vince

 

[Steve Fabian]

| It doesn't answer the questions, especially the CMD compatibility
| one, but using the much more powerful IFF/ENDIFF would, I believe,
| make all the problems go away.

Agreed.

| I've never needed CMD compatibility

Nor I - I have never needed to code for CMD, and do not know its intricacies
or foibles.

| and wouldn't mind if IF simply went away.

That I would mind - I would hate to convert all my "IF x DO y" statements
(with DO actually just implied, not physically present) to "IFF x then %+ y
%+ ENDIFF" multiliners. However, I never use multiline command groups.
Either they fit on a single physical line, or they are already written with
IFF / ENDIFF.

Luckily, I have serious doubts Rex would ever do such a thing.
--
Steve

 

[John Posner]

Thank you all for your helpful comments!

Does anyone think that this situation merits a sentence in the Command Grouping section, stating that labels shouldn't be used in a command group?

Tx,
John

 

[Steve Fabian]

| Does anyone think that this situation merits a sentence in the
| *Command Grouping* section, stating that labels shouldn't be used in
| a command group?

It would be harmless, but it would be a duplication of the sentence below in
topic "goto.htm":

The label must begin with a colon [:] and appear on a line by itself.

If anything is added to topic "grouping.htm", it ought to include all the
other commands which need to be on a line by themselves and thus ineligible
to be in a command group, e.g., DO and ENDDO, TEXT and ENDTEXT.
--
Steve

 

[dcantor]

| Does anyone think that this situation merits a sentence in the
| *Command Grouping* section, stating that labels shouldn't be used in
| a command group?

It would be harmless, but it would be a duplication of the sentence below in
topic "goto.htm":

The label must begin with a colon [:] and appear on a line by itself.

If anything is added to topic "grouping.htm", it ought to include all the
other commands which need to be on a line by themselves and thus ineligible
to be in a command group, e.g., DO and ENDDO, TEXT and ENDTEXT.
--
Steve

Perhaps the statement in file goto.htm could be amended to say:

The label must begin with a colon [:] and appear on a line by itself, and not within a command group.

 

[rconn]

> Consider this batch program, stored in "test.btm":
>
> @echo off
>
> if "%1" == "" goto helplabel
>
> if "%1" == "help" (
> :helplabel
> echo this
> echo is
> echo helpful
> goto end
> )
>
> :end
>
>
> With CMD.EXE, both "test" and "test help" produce the same 3-line
> output. With TC11, "test" produces the 3 lines, but "test help"
> produces no output.
>
> It looks like TC11 doesn't like the occurrence of a label within a
> command group. There's no mention of this in the "Command Grouping"
> documentation. In the GOTO command description, there's a discussion of
> "to avoid errors in the processing of nested statements", but there's
> no specific mention of command grouping.
>
> Is this a doc omission?

This is not the worst example of CMD syntax mangling I've ever seen, but it
definitely belongs in the top 10!

The reason it works with no argument is because the parser has not collapsed
the command group into a single line, and the GOTO will find ":helplabel" on
a separate line. The reason it doesn't work *with* an argument is because
everything in the command group HAS been collapsed to one line, and
everything following the ":helplabel" is assumed to be local GOSUB variables
(a TCC feature which CMD lacks).

I'm not going to remove local variables in order to support this
(never-seen-before) syntax, particularly since I cannot imagine why the
author needed to do this in the first place, even with CMD.

Rex Conn
JP Software