Why does this batch file give me 'unknown command "else"' error?

[MickeyF]

I've created a batch file that has evolved over the years. The beginning part of the batch file's purpose is to look at the command line argument, if supplied, and then take a step based on the value. (It will require reading the header of the batch file to understand what I'm about to discuss further.)

If I invoke the batch file with no arguments, with /i, /mi or /q, the flow works properly, and it does what I want. If I use the /v=3.4.29.1 (or any other version number), which is the part I recently added, it seems to get confused on the 'iff'/'elseiff'/'endiff' sets, and eventually comes to the 'else' on line 79, which should match up with the 'iff' on line 45.

TCC: C:\Utils\ISBuild.btm [79] Unknown command "else"

Any help on figuring out how to track this down? I've hand-drawn the matches and can't find any problems, and I've also run it under the debugger, to no avail. I doubt there is a problem with the user functions and other user batch files called, because I haven't changed them in several years, and I've also used 'call' in front of the batch files for safety. If you need to see the function definitions, I can provide them.

I'm using TCC 16.03.55 x64 Windows 7 [Version 6.1.7601]

Any help provided would be greatly appreciated.

 

[samintz]

I am not certain, but I think that TCC treats equal signs as separators. So instead of getting a single variable whose value is "/v=3.4" you get 2 variables with values "/v" and "3.4". Could that be what's happening?

 

[Charles Dye]

I'm not seeing your batch file.

When I've had this problem in the past, it's usually because I typed IF where I wanted IFF.

 

[MickeyF]

I'm not seeing your batch file.

When I've had this problem in the past, it's usually because I typed IF where I wanted IFF.

I've triple-checked all of my IFF statements and can't see anything wrong. Maybe some eagle-eye will spot something I missed.

I wish there was some better way of finding these blasted mismatches. Sometimes it's due to the program flow, but I can't even see a possibility for anything like that here.

BTW, the file should be available as an attachment. Do you not see an attachment?

 

[MickeyF]

I am not certain, but I think that TCC treats equal signs as separators. So instead of getting a single variable whose value is "/v=3.4" you get 2 variables with values "/v" and "3.4". Could that be what's happening?

That's a good suggestion, but my handling of the command line shouldn't care. I'll double-check it, though.

 

[Charles Dye]

BTW, the file should be available as an attachment. Do you not see an attachment?

I'm afraid not.

Another way to gork IFF and DO structures is by trying to do a GOTO inside them. Use GOTO /I, or (better) rewrite to eliminate the GOTO.

 

[MickeyF]

I don't have any GOTO statements. Yeah, they are really bad.

I tried to upload the file again, and now I see that something is blocking it. When I select the file and click OK, it then shows me the file symbol with the filename next to it, but stricken out. I'll try zipping it and uploading the .zip file.

 

[vefatica]

This (line 62) looks a bit fishy.

if %@attrib[%_ISMFile,r] = 1

I have no idea whether it's related to the error in question

 

[K_Meinhard]

Line 88/89

elseiff (%1) == () .or. (%1) == (/q) .or. (%1) == (/i) then
    rem set _Build_Param="%@iniread[%@sfn[%@expand[*.ipr]],Data,CurrentMedia]"

leads to an empty elseiff branch. For testin, replace rem with echo.

 

[MickeyF]

This (line 62) looks a bit fishy.

if %@attrib[%_ISMFile,r] = 1

I have no idea whether it's related to the error in question

What's fishy about it? %_ISMFile is an environment variable pointing to the name of the file that I want to test. It returns either 0 or 1. Oh, and the full line is:

if %@attrib[%_ISMFile,r] = 1 echo Not modifying project version because project is read only.

That looks properly formed to me. What am I missing?

 

[Charles Dye]

if %@attrib[%_ISMFile,r] = 1 echo Not modifying project version because project is read only.

That looks properly formed to me. What am I missing?

The equality test should be a double equals sign ==. I really don't think that's your problem, but technically it is incorrect syntax.

 

[Charles Dye]

Line 88/89

elseiff (%1) == () .or. (%1) == (/q) .or. (%1) == (/i) then
    rem set _Build_Param="%@iniread[%@sfn[%@expand[*.ipr]],Data,CurrentMedia]"

leads to an empty elseiff branch. For testin, replace rem with echo.

I don't understand. What's wrong with a REM inside an IFF block?

 

[MickeyF]

The equality test should be a double equals sign ==. I really don't think that's your problem, but technically it is incorrect syntax.

Ah, good eye, as my old Little League coach used to say. Didn't solve the problem, though.

 

[MickeyF]

I don't understand. What's wrong with a REM inside an IFF block?

Nothing. That's a section of code that is extremely rarely used anyway, but I probably did that a long time ago for testing purposes. I've removed the REM to put the original statement back into place. Of course that's not the problem, because that section of code isn't even being exercised anyway. I'm using the part inside the iff "%@expand[*.ism]" != "" then (for building InstallShield .ism project), rarely ever the else part (for building InstallShield 5.5 project). And my problem occurs when testing with a .ism file, and only when I use the /v=1.2.3.4 switch.

 

[vefatica]

How "/v=1.2.3.4" is interpreted will depend on the value of the INI directive CMDBatchDelimiters. If not specified the default is "Yes".

v:\> type test.btm
echo %%$ is %$
echo %%1 is %1
echo %%2 is %2

v:\> option cmdbatchdelimiters
cmdbatchdelimiters=No

v:\> test.btm /v=1.2.3.4
%$ is /v=1.2.3.4
%1 is /v=1.2.3.4
%2 is

v:\> option //cmdbatchdelimiters=Yes

v:\> test.btm /v=1.2.3.4
%$ is /v 1.2.3.4
%1 is /v
%2 is 1.2.3.4

 

[MickeyF]

How "/v=1.2.3.4" is interpreted will depend on the value of the INI directive CMDBatchDelimiters. If not specified the default is "Yes".

That may be true in a newer version, but I'm using TCC version 16.03.55, and that option doesn't exist.

However, I can state that the version number is getting passed nicely to my batch file. I'm getting the right string to use.

Just for evidence, I created your batch file. Here's the output:

->test.btm /v=1.2.3.4
%$ is /v=1.2.3.4
%1 is /v=1.2.3.4
%2 is

I appreciate the assistance each of you is providing. I remember Vince, Charles and Scott from back in the 4DOS days!

 

[vefatica]

CMDBatchDelimiters exists in my version 16.03.55. Apparently it's set the way you want it.

"MickeyF" is vaguely familiar from the old days.

 

[MickeyF]

CMDBatchDelimiters exists in my version 16.03.55. Apparently it's set the way you want it.

"MickeyF" is vaguely familiar from the old days.

Yeah, it's been a long time since I needed assistance here. That's a good thing!

I just realized that the option name is case sensitive. I had just typed it in directly without worrying about its case. It's currently set to 'No'. Which it would appear is what I want. Anyway, as it is right now I have an ugly goto in there to skip past the trouble stuff. It's a hack, but it does work... If no one can find my bug, at least I have a workaround.