Ctrl-C doesn't work right [EDIT: nevermind, i'm wrong]

[ClaireCJS]

Windows Terminal version

1.21.2911.0

Windows build number

10.0.19045.5011

Other Software

TCC command line

Steps to reproduce

^C and Ctrl-Break have always both behaved slightly differently, and for almost 40 years of command-line scripting, my way to emergency exit scripts has been to alternate between the two.

Instantly, upon wrapping my TCC command line (which has been in constant development and used by me almost these entire 35-40 years) ... Problems with this. Problems with stopping scripts.

Sure, if they are nested, it can be an interpretation to only break the lowest level of the nest and return back.

But I'm not just seeing that.

I'm also finding tons of other complaints from other people about this, but most of the closed issues are for special circumstances that clearly are not applying here.

I'd like to get to the bottom of this. I literally cannot escape scripts without having to close my window. It was NOT like this with the exact same command line outside of WT.

I initially took my complaints to Rex, author of TCC, with the response:

"^C handling is being done by Windows Terminal before TCC sees it; there's nothing that TCC can do about that."

Which would quite adequately explain why the key is about 75% nerf'ed in WT compared to TCC. 75% because it's a fuzzy hard-to-define problem, which is probably why it's not been fixed.

Expected Behavior

^C ends things. At the very least, it ends the .BAT being called by another .BAT

Actual Behavior

Doesn't do that. I end up having to close the terminal window entirely. I lose my environment variables and current folder location.

[vefatica]

Steps to reproduce please (simple ones).

What forces you to close the WT window?

I use WT all day long, every day. I have no complaints about ^C.

[ClaireCJS]

Steps to reproduce please (simple ones).

What forces you to close the WT window?

The inability to get out of ^C and ^Break [historically, it has required alternating between both to get out of the toughest situations, and always been like that on every machine since the 90s]

I use WT all day long, every day. I have no complaints about ^C.

That's great, but your personal experiences are irrelevant to mine and stating them as if they mean something is incredibly condescending. All 6 billion people on the planet could each leave that comment, and it would be no proof of anything one way or the other, unless you were trying to prove that it works sometimes. And it sure does work sometimes. But not always.

[vefatica]

I don't mean to be condescending. It's just that your experience, compared to mine, is very surprising.

I'd like to know how to get into one of those "toughest situations". Then I'd have something to try to figure out.

[ClaireCJS]

No worries. It's just a very frustrating situation to me.

Yea. I pretty much noticed it the day I switched, and tolerated it for 2 years up until this week when the CANCEL command in TCC started failing me this week, leaving zero outs.

It seems that ^C processing is so slow that we reach the next line of the BAT before it hits, but that's such a simplification of what must be really happening and it might be a 100%-wrong simplifcatino.

I'd also love to know the under-the-hood difference between ^C and ^Break because i've been in a million situations where one seemingly works while the other doesn't. Like hit one 20X without exit, hit the other and get exit 1ˢᵗ try. It's how I grew up learning to alternate between ^C and ^Break. And that's a behavior i've experienced since at least 1990, regardless of computer, operating system, keyboard, or command line (tho i've always use TCC, sine 1988).

Sometimes I wonder if the hidden answer to this new ^C problem lies in the difference between ^C and ^Break, but that's a total shot in the dark.

The responses to issues here on the Github are usually super low-level responses that are over my head, but extremely satisfying to read in terms of gaining a gleam of understanding of why things happen. They've definitely fixed a thing or two because of me and it's been a good feeling to contribute. All too often it ends up being an already-discovered bug manifesting in a different way, but this one doesn't seem to resemble any of the currently-open issues.

I thought I'd discussed it here with the Terminal staff before, but i looked through my old discussions and couldn't find it. I'd tabled the issue because i could work around it, but it's gone on so long i just have to raise an Issue here on Github cause i'm at wit's end. I've lost files because of it. Fortunately I have a good backup plan... [my most important files are auto-copied to EVERY drive letter, so i have like 15 copies of some things....idea being that just one harddrive surviving a house fire would bring it all back]

[Zeroes1]

@ClaireCJS i test cmd line for profile: C:\UTILITY\TCC\tcc.exe test.bat where test.bat dir /S c:\windows\

Ctrl-C and Ctrl-Break work fine win10 22h2 tcc-rt.exe v33.0.18.0 checked on: terminal-1.17.11461.0 terminal-1.23.3101.0

[ClaireCJS]

@ClaireCJS i test cmd line for profile: C:\UTILITY\TCC\tcc.exe test.bat where test.bat dir /S c:\windows\

Ctrl-C and Ctrl-Break work fine win10 22h2 tcc-rt.exe v33.0.18.0 checked on: terminal-1.17.11461.0 terminal-1.23.3101.0

Amazingly, there exists more than 1 situation. Something working for you doesn't mean there isn't a bug. And that example would totally work for me. It's not real-world that's a proof of concept that ^C can work at all. Of course it can. It often does. But not always, and at a different rate under TCC with Windows Terminal than not.

I've likely been doing this since before you were born, and I'm waiting for qualified professionals who run this project to respond. They often give the most excellent explanations.

[Zeroes1]

@ClaireCJS

I'm afraid to disappoint you, but you can wait for years for an answer or a solution here. 1.5k open tickets now.

ps. i'm use windows and console ~30year.

pps. You checked on clear (default) Windows, default WT? what is the probability of a problem? need more data... exist real conditions for maximum probability of reproducing problem?

[ClaireCJS]

"Default" windows terminal? You either have windows terminal or you don't.

But yea, before the windows terminal days, it wasn't like this.

I need to find a concrete example but i don't even know how to open up TCC outside of windows terminal, lol. If i run TCC.exe at the start menu, or even CMD.exe, it automatically opens up in windows terminal and i don't know how to disable that.

[vefatica]

i don't even know how to open up TCC outside of windows terminal

This should give you TCC in a Windows console.

c:\windows\system32\conhost.exe [path]\tcc.exe

This will also, perhaps for comparison.

[path]\OpenConsole.exe [path]\tcc.exe

[ClaireCJS]

i don't even know how to open up TCC outside of windows terminal c:\windows\system32\conhost.exe [path]\tcc.exe> This will also, perhaps for comparison.> [path]\OpenConsole.exe [path]\tcc.exe

Thanks!!! 2 new bat files...

For the 2ⁿᵈ one, My only openconsole.exe that wasn't in the Windows Terminal folder was C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\Terminal\ServiceHub\os64\OpenConsole.exe, so I went with that.

[ClaireCJS]

I do have a question for anyone —

1) Is there any key that cancels ALL bat files, even if you're nested, to go completely back to the command line?

2) Is that the intention of Ctrl-Break vs Ctrl-C?

[vefatica]

I suspect the OpenConsole.exe in the WT folder is newer. I'd use that one.

I don't think there's such a key. But you can put ON BREAK CANCEL in your BTMs.

[ClaireCJS]

I suspect the OpenConsole.exe in the WT folder is newer. I'd use that one.

🦇🦇🦇And now i have 3 new BATs! 🤣

I was avoiding it on the incorrect intuition that i'm avoiding Windows Terminal 🤦🏻‍♀️

I don't think there's such a key. But you can put ON BREAK CANCEL in your BTMs.

😲 WHAT 3,826 BAT files in my \bat\ folder and not a single one with this. Don't know how I missed that. Holy 🐄, this may be the solution to my problems!! Thank you!!!

[ClaireCJS]

I don't think there's such a key. But you can put ON BREAK CANCEL in your BTMs.

🎈 OMG i can't believe it. It completely fixed the situation.

Though I still have issues with TCC's cancel not really canceling if it's enclosed in an if, and may alias it to a BAT file so that it's technically not enclosed in an iff, but that's out of scope for Windows Terminal, and likely won't come up now that ^C actually works :)

I don't know how i missed this one for 35 years. Or why things worked better before WT. But this is great.

Thank you! I've had so much anxiety around this issue for years. Everything i use in any bat now goes through validate-environment-variables (which also checks existence if it's a path), validate-is-function (only works for user functions, not internal), and validate-in-path (works for internal/anything). Everything has an errorlevel checker afterwards that checks in a couple ways and gives option to cancel.

It's helped, but I still need to ^C out of stuff regularly, and it was driving me nuts. Sorry I was so grumpy about it earlier. Thank you from the bottom of my heart!

[Zeroes1]

@ClaireCJS i mean default options of WT :) for example You can download latest nightly build WT https://aka.ms/terminal-canary-zip-x64

unpack this, it's portable version, make lnk file on desktop to WindowsTerminal.exe add new profile for tcc for test and check situation.

wt make new options inside dir \settings -> no confict with default WT inside Windows OS