Welcome!

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

SignUp Now!

Why does ^C and ^Break hardly work in Windows Terminal?

Jul
274
6
It's been frustrating. I enjoy TCC way more under Windows Terminal, with the panes, tabs, emoji, ANSI, etc....

But Ctrl-C and Ctrl-Break [which both behave slightly differently, so i tend to rapidly alternate between the two of them when i REALLY want to end a deeply nested BAT-file situation] are completely nerfed under Windows Terminal.

If someting goes awry, I have to close the tab. ^C and ^BREAK work sometimes, but the effectiveness has gone from 99% to 20% or so.

Wondering why this is.
 
Can you provide an example, complete and the simpler the better, of something you can interrupt in a console but cannot interrupt in WT? Here, Ctrl-C works the same in WT as in a console. I never use Ctrl-Break.
 
I mean pretty much any time you want to abort anything. Even a one line global command.
 
I mean pretty much any time you want to abort anything. Even a one line global command.
Not here. I just spent about 20 minutes trying various GLOBAL commands (in/out of BTMs, several FFIND commands too) with TCC v32 in Windows Terminal. I didn't count but I reckon I did 30-40 tests. Every time, the command was terminated immediately.

Please give a specific command which you can't interrupt with Ctrl-C in Windows Terminal (and can interrupt in a console).
 
My problem is once you install WT it's not possible to run TCC outside of it to do a comparison.

These days, i don't even bother with ^C. It flat out has cost me file deletions by failing to stop. I close the pane. It's the only way to be sure. This problem manifesting constantly has been enough to untrain a lifetime of ^C.

It's particularly annoying because i inevitably have navigate back to the same folder I was in.
 
I'll try to find an example but I won't be able to compare it.
 
okay very simple one

global /i /n echo *copy c:\delme-gigapixel-art-scale-6_00x.jpg c:\recycled\

which is really the equivalent of:

global /i /n echo Hello


The ^Cs don't work. They spit out at the end. If this was a runaway file deletion situation it would be very very bad to not be able to abort it. If I run this in my root folder as just "echo hello", it's impossible for me to abort it. I can't even close the dang tab because it eats up so much resource.

1716048491464.png
 
I really wish I hadn't tried this in my root folder. I literally cannot stop it and I can't even select another tag while it's running. Even the 'x' button on the tab doesn't work because the the loop for "Echo hello" is so tight that whatever bug is preventing ^C from hitting the process is not even letting the process be closed via the 'x' button on windows terminal's tab. THAT aspect is likely a windows terminal bug, but how about my ^C never hitting the global command?

Still running. Still in my windows folder. Still unabortable unless i taskend the specific process #.
 
I should note that I only experience this on my primary computer running TCC 31.01.15
but not on my wife's computer running TCC 31.01.15
and not on my secondary computer running TCC 29.00.17

So it ,may be a setting, but what setting would (or even could) do this?

Literally, my wife & I sit down together and copy all our settings from one machine to another manually when setting up something new like...this. We should have the same settings.

I wonder if it's something more deep-seeded like video driver interaction with console sessions. I have an older RTX card than her.
 
My problem is once you install WT it's not possible to run TCC outside of it to do a comparison.

Why do you think that? I have Windows Terminal installed on both my home and work machines, but mostly run TCC in Take Command, or occasionally in a plain old console window.
 
Your GLOBAL command worked fine here with both TCC31 and TCC32 in Windows terminal.

There's probably an easier way (even if WT is the default), but the likes of this should start TCC in a console.

Code:
c:\Windows\System32\conhost.exe d:\tc32\tcc.exe
 
Running tcc,exe creates an instance of windows terminal.
 
And what if you run this with a correct path to tcc.exe?

c:\Windows\System32\conhost.exe drive:\path\tcc.exe?
 
Nice. I never knew you could call conhost directly. Thanks!!

^C works great there!

So... what do I do, open up a bug with the Windows Terminal people? :nervous laugh:
 
Just for documentation sake (in case i refer the WT people to this thread), these are my WT settings for TCC


1716066999801.png


1716067078599.png

1716067031669.png

1716067052680.png
 

Attachments

  • 1716067071437.png
    1716067071437.png
    55.9 KB · Views: 7
So... what do I do, open up a bug with the Windows Terminal people?
I'd wait until I could make a better case, like one that didn't depend on TCC, or other TCC users seeing the same thing. Have you tried Ctrl-C in CMD? DIR /S on the system drive would be a good one to try in CMD.
 
Maybe an obvious question, but if you type BREAK at the command line, does it say that break handling is on or off?
 
Maybe an obvious question, but if you type BREAK at the command line, does it say that break handling is on or off?

Good call, that's not obvious to me :)

<11:35p> <32%> C:\>break
BREAK is ON
 
I'd wait until I could make a better case, like one that didn't depend on TCC, or other TCC users seeing the same thing. Have you tried Ctrl-C in CMD? DIR /S on the system drive would be a good one to try in CMD.

It works fine for dir/s though. It's mostly in BAT files that this happens. Particularly if they are nested.
 
It's mostly in BAT files that this happens. Particularly if they are nested.
If the BAT file you're interrupting (most likely the most deeply nested one) is being CALLed in a loop by a BAT file higher up the nesting chain, that higher up BAT file will continue CALLing the one you've interrupted. That is, Ctrl-C and Ctrl-Break don't travel up a nested sequence of BAT files.
 
We still have a problem here.

The global command is not a nested bat file. And it works differently in WT than conhost. And only on one machine.

There is definitely a problem. Is this a problem that can be solved?
 
What version of Windows Terminal do you use?

If not the newest, maybe this is a bug that was fixed in a later version.
I am also using TCC with WT and never saw anything like this when using GLOBAL.
 
Back
Top
[FOX] Ultimate Translator
Translate