Welcome!

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

SignUp Now!

SOLVED: So how do you actually CANCEL, if CANCEL doesn't really CANCEL? [answer: make sure it's not within an if/iff, or move it to a separate BAT]

Jul
532
10
Seriously. The documentation is a lie

"CANCEL command - Terminate batch file processing
The CANCEL command ends all batch file processing, regardless of the batch file nesting level. Use QUIT to end a nested batch file and return to the previous batch file. "

I'm literally echoing "returning to the command line" immediately before CANCEL.

Yet... it returns to the calling BAT file.

That's what the documentation says QUIT is supposed to do.

I'm not using QUIT, i'm using CANCEL.

And it doesn't.

If i'm using it wrong, the docs should say that?
 
Can you be more precise? Here, QUIT and CANCEL seem to work as documented.

Code:
v:\> type bat1.btm
call v:\bat2.btm %1
echo back in bat1

v:\> type bat2.btm
echo in bat2
if "%1" == "cancel" (echo returning to the command line & cancel) else (echo returning to bat1 & quit)

v:\> bat1.btm
in bat2
returning to bat1
back in bat1

v:\> bat1.btm cancel
in bat2
returning to the command line

v:\>
 
This is my source. I know it's getting to the cancel command because:

1) I am literally echoing a unique echo statement that exists nowhere else and is definitely the line of code here
2) the next line is literally cancel
3) I am not being returned to the command line.


Code:
``iff %DO_IT eq 1 then
        title %prev_title%
        pause
        set FORCE_EXIT=1
        echo on
        echo %ANSI_COLOR_RED%—— Returning to command line #1 of 2 ——%ANSI_COLOR_NORMAL%
        CANCEL
endiff

if %DO_IT eq 1 (
    echo %ANSI_COLOR_RED%—— Returning to command line #2 of 2 ——%ANSI_COLOR_NORMAL%
    echo on
    CANCEL
) %+ rem Redundant double-cancel just-in-case {having some suspicious behavior as of 2024/10, bug reported 2022/11/10}

Full source of this is at:

This is a utility script to refactor all potential exitings in all scripts for nonfatal errors, after checking for errorlevels. I use it everywhere. If i say no, it continues on with the calling script. If i say yes, it exists to the command line.

Except when it doesn't. Which is nonzero.

I'm now changing cancel to *CANCEL (but i checked, there are no aliases and nothing in path with the same name) and turning echo on prior to doing it ... but i'm not sure how much more sure i can be than i am now. If the echo before cancel is happening, then cancel is happening. Right?


So if my understanding is correct, absolutely under no circumstance ever should this not return me to the command line.

Replicating the surrounding conditions would likely require importing my entire github. Everything is connected and refactored. The end-run is... Here i am canceling and it's not canceling. It's happening before my very eyes.
 
Between this

...and WT's apparently unsolved bug processing ^C correctly, which nobody can report to them in a way to get them to fix, even though i'm sure somebody smarter than me could figure it out...

It's nigh impossible for me to stop anything runaway without closing the window entirely.

Should be as easy as it was 10, 20, 30 yrs ago, but it's not.
 
That's hardly something one could use to try to duplicate the problem.

Code:
TCC: (Sys) D:\tc33\claire1.btm [3]  Incorrect function.
 "%@ANSI_BG[40,0,0]"
TCC: (Sys) D:\tc33\claire1.btm [5]  Incorrect function.
 "%@ANSI_BG[40,0,0]"
TCC: D:\tc33\claire1.btm [14]  Unknown command "askyn"

WT's apparently unsolved bug processing ^C correctly

What are you talking about? I use TCC in WT all day long. I have no problems with Ctrl-C.
 
What are you talking about? I use TCC in WT all day long. I have no problems with Ctrl-C.

Must be nice. I do. And the big reports in windows terminal and various comments in forums about it are out there. It wasn't night and day or 100%-anything, but it was a big difference.
 
That's hardly something one could use to try to duplicate the problem.

Code:
TCC: (Sys) D:\tc33\claire1.btm [3]  Incorrect function.
 "%@ANSI_BG[40,0,0]"
TCC: (Sys) D:\tc33\claire1.btm [5]  Incorrect function.
 "%@ANSI_BG[40,0,0]"
TCC: D:\tc33\claire1.btm [14]  Unknown command "askyn"

Those are just cosmetics. Echo'ing of ansi codes nothing more.

function ANSI_BG=%@CHAR[27][48;2;%1;%2;%3m
function ANSI_FG=%@CHAR[27][38;2;%1;%2;%3m

Lotta convenient stuff in my set-ansi.bat for easy formatting...

This script is pretty meaningless run on it's own, though. I've never seen it fail just from being run straight-up (which makes no sense anyway). And therein lies the problem. The command should behave consistently.

If the echo before it is happening... why would it not be happening?
 
Last edited:
Random idea: Could it be some artifact of using iff?

I recently changed from using if to iff
 
I suspect this issue is due to a misunderstanding of how CANCEL works. It is not like hitting ^Break and having it automatically terminate all batch file processing. What CANCEL does is set the batch file read pointer to the end of the file, so after the current command line is processed, the batch file(s) will terminate. However, if you have compound commands (or something like IF, which is also a compound command) the remainder of the command line will be processed before exiting the batch file(s).
 
Interesting.

So how does one conditionally cancel, then?

I guess... Stick it in a separate BAT file and conditionally call that instead of just saying 'cancel' in an iff

Thanks. I never would have thought of that in a million years without this extra understanding.
 
Also feel like maybe the help page could mention this so future people don't get stuck wondering why cancel isn't canceling for them....

i'm reverting from iff-endiff and going with a simple if-goto instead. And also moving cancel into a separate bat file anyway. And changed it in a dozen or so scripts. Two-pronged fix i hope!


is there anything that actually takes you back to the command line?
if ^C breaks the current BAT but returns you to parent BAT, could ^BREAK be made to return to command line?
 
Last edited:
Back
Top