Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

WAD Breakpoints don't work on If's

rconn said:
An IF is one line, and one statement.

The execution pointer will pause at the end of the IF (line 78), which makes sense as you wouldn't be able to single-step to the next line in the batch file (79) if execution paused at line 76.
Click to expand...
Except that's not what you've been telling me.
 
The command links also function properly here. Firefox Desktop, newest release ...
 
Works correctly also on Android here with Firefox Mobile latest release...
 
Yes, really weird ... have also no idea ...
 
So here's the IF that's crapping out my script in the debugger. Anyone see the problem? Look at the redirected filenames. There's a quote missing on the drive side or the inverse you need to remove the last one after log. I wasn't even thinking that would cause a change in the execution path. I think this has solved the front end problems. The console log which was just appending every command from the first problem to the end of the script is now empty or clear of anything. There still could be something that hasn't been traversed, a path not taken that could cause future problems. This is often how software remains buggy. When the tester gets through the script and gets the desired results they claim victory but unless you've tested every branch you can't claim victory.

1000007359.webp


The debugger executes line 85 it goes to the last line in the script. I checked for unmatched parens across the script but found nothing. I did the same for brackets and found nothing. What I found was that a paren was not spaced on the first line of an IF structure. So instead of
Bash: 
If A < B (
it was
Bash: 
If A > B(
. There's no rule for spacing parens in CMD but I guess I've proven that inside CMDebug there is. I wasted countless hours on figuring this out. The other error I found was a missed " around a filename (discussed above the image) just like the paren was screwing up execution but that I think it should have been reported aa syntax error. CMDebug needs some checking for matched quotation marks and the other need is verifying parens and brackets are matched within a command structure so the outside IF to the last or closing paren. This will resolve a lot of problems concerning breakpoints and odd errors past the last line of the script and jumping to the last line in the script. For now at least there are some answers that maybe some of you had learned through experience with CMDebug.

In NotePad++ there is a Plugin called BracketsCheck that will check for () {} [] and <>. I put in a request to add quotation marks. I didn't specify double or single maybe I should to ensure both would be included. You can select which ones you want to check. <> can be kind of weird because of redirection and checking values > or <. It may not be a bad idea to add plugins to CMDebug to take advantage of these existing functions.
 
Wow, that's a bit of a tricky problem.

CityguyUSA said:
There's no rule for spacing parens in CMD but I guess I've proven that inside CMDebug there is.
Click to expand...

I'm not seeing the same results on my system.

Under CMD.EXE I get this.

Code: 
C:\>if 10 GTR 5 (echo Hello & echo There)
Hello
There

C:\>if 10 GTR 5(echo Hello & echo There)

C:\>
C:\>ver

Microsoft Windows [Version 10.0.26200.8655]

So no error for a left paren without a leading space, but the if comparison doesn't do what I want either.

Not sure exactly how CMD is parsing that line. If it's treating the left paren as part of the second string in the comparison, then when it finds that 10 is not GTR 5(echo it apparently doesn't do anything with the remainder of the line...so no error is thrown for Hello & echo There)



At a TCC Command line (in a Take Command tab) I get this

Code: 
[C:\Program Files\JPSoft\TCMD36]if 10 GTR 5 (echo Hello & echo There)
Hello
There

[C:\Program Files\JPSoft\TCMD36]if 10 GTR 5(echo Hello & echo There)
Usage : IF [/I] [NOT] condition [.AND. | .OR. | .XOR. [NOT] condition ...] command

[C:\Program Files\JPSoft\TCMD36]if 10 GTR 5( echo Hello & echo There)
Usage : IF [/I] [NOT] condition [.AND. | .OR. | .XOR. [NOT] condition ...] command

So a missing space in front of the left paren generates a usage error for me.

And running the same first two commands from a script in BDebugger gives me this

Code: 
[C:\Program Files\JPSoft\TCMD36]BDebugger
QCal plugin v1.7.4 loaded.
ScreenShot v1.1.4 loaded.

if 10 GTR 5 (echo Hello & echo There)
Hello
There
if 10 GTR 5(echo Hello2 & echo There2)
C:\Batfile\TestTest.btm [2]  Usage : IF [/I] [NOT] condition [.AND. | .OR. | .XOR. [NOT] condition ...] command

[C:\Program Files\JPSoft\TCMD36]

Same as at the TCC command line.



I realize that the A > B was not your actual code...but still I'm not seeing the same behavior you describe.

Are you not getting a usage error when you execute your if code with a left paren not preceded by a space?
 
I didn't actually code an example. I was spending hours trying to find what was causing these bizarre skips in execution and while the error I was getting was similar to what you say about the IF.... in your TCC example the only thing I saw was that space missing before the "(" on the first line. When I moved it things changed dramatically. That made me search for information regarding a requirement for command blocks to have a space before either paren and I could only come up with there was no requirement to have a space per whatever AI Brave uses.

However, after your response that obviously ins't correct (not the first time I've gotten burnt by not chasing the AI answer further but most of the time I know that's it's not correct this was an unknown to me). Doing it again this time I'm guessing my wording was different enough to get the real answer:

The space before the opening parenthesis in a Windows CMD IF statement is mandatory syntax when using code blocks.​
​
1. Syntax Requirement The CMD interpreter requires a space between the conditional expression and the opening parenthesis to distinguish the end of the condition from the start of the code block.​
​
Correct: IF "%1" == "value" ( command )​
Incorrect: IF "%1" == "value"( command )​
2. Parsing Behavior CMD uses a line-at-a-time parser. Without the space, the interpreter may fail to recognize the IF block structure or treat the parenthesis as part of the previous token, leading to syntax errors or unexpected execution paths. ​
​
3. Variable Expansion Note If you are seeing different results related to variable values inside IF blocks (e.g., %var% not updating), this is due to parse-time expansion. To use updated variable values inside a block, you must enable Delayed Expansion and use exclamation marks (!var!) instead of percent signs.​
​
Bash: 
@echo off
setlocal enabledelayedexpansion
set x=0
IF %x% == 0 (
    set x=1
    echo !x!  :: Prints 1
)

This example does follow the rules of command blocks or code blocks or whatever they're calling them. It prints the 1 and says it Prints 1. If I take the space away it gives a syntax error "The syntax of the command is incorrect". Which command I don't know. If I removed the last paren the ")" it doesn't give any error or any message. If I drop the space before the first paren and forget the closing paren I get an error saying, "The syntax of the command is incorrect" so seems to return the same error as if the space is missing before the leading paren but very ambiguos on what command is causing the error. I think the code block needs to be syntaxed on it's own.

I'm curious about the == which forces a string comparison.

I wasn't getting any syntax errors running my script in command. A syntax should shut it down or so I thought and this IF was up front in the code one of the first but without going back and investigating I'm just confused at the moment. However, lacking the inline echo's to display values I really don't know how it's executing other than getting to places later in the script and then there's the implication of enabledelayedexpansion pushing out when it actually evaluates the statement does that include syntax? It would take a bit to get back the previous script if I even have a backup at that point in time.

The other error I got was ) unexpected at this time. From looking at things I've just been looking at that can occur from a bad statement in the code block a particular one they mention is :: or what I think of as a comment doesn't work right in a code block. I thought there was some of those in there but I went back to look and didn't find any.

We have multiple responses from CMD. There's the space ( where it executes as expected but the missing space is unpredictible. It might throw and error or it might not. Your getting consistant results in the debuggers which is a step in the right direction but it didn't identify it as a code block error but an IF statement error. My script in CMDebug reported the IF syntax like your tests but continued on it's merry way rather than stopping but like the MS Documentation it wasn't following a predictible execution path. I put in a suggestion that they add some upgraded syntax checking based on this documentation which is still evolving at the moment.
 
You must log in or register to reply here.
Back
Top