[Bug] Control Key gets stuck.

[jsmunroe]

Description of the issue

The control key appears to get stuck as pressed. At some point while using Cmder, when I backspace it erases whole words and when I hit up or down to scroll through command history, it changes the existing line to "[A" for up and "[B" for down. Left and right are "[D" and "[C" respectively. I have to restart it when this happens.

It has been happening rather frequently ever since the last update.

After hitting Up key

How to reproduce

It happens after a random amount of time. I do not know what action triggers it.

Additional context

Full disclosure, I am not certain that this isn't ConEmu, Clink, or other third-party tools that Cmder uses. I'm not sure how I would be certain of that or why that is relevant. If someone had a problem with one of my projects that was a bug with something it was using, that is still a bug in my project. I would want it fixed even if it wasn't directly a problem with my project. But reports help you out too.

I did search for existing problems within the ConEmu space and didn't find anything. I don't see any like issues in the ComEmu GitHub repo.

[DRSDavidSoft]

Thank you for reporting this bug.

Can you please use the unmodified ConEmu for some amount of time to see if this issue can be reproduced with only ConEmu?

Additionally, please use Cmd.exe shell instead of clink if you can, to see if this issue is related to ConEmu or not.

[chrisant996]

It sounds like the ConEmu terminal mode may be getting stuck in "XTerm" mode.

In the XTerm mode, arrow keys and other special keys get inserted in exactly the way you describe.

ConEmu tries to automatically figure out when to use Windows vs XTerm mode.
See ConEmu docs Terminal input and output modes for details.

To make ConEmu show the current terminal mode:

1. Open the ConEmu Settings dialog.
2. In the tree view on the left, choose "Status bar" under the "Features" heading.
3. Make sure the "Show status bar" checkbox at the top is checked.
4. In the "Available columns" list, find and double-click on "Terminal modes" to add it to the status bar.
5. Click "Save Settings".

Now the status bar will show "W" for the normal Windows mode, and "X" for the XTerm mode. (There may or may not be a "K" or other letter next to it as well.)

[jsmunroe]

It shows Wk in the status bar when the problem exists. Here are the status bars for two windows, the top has the problem, the bottom is a brand new window that does not have the problem.

[chrisant996]

@jsmunroe In any case, this seems like a ConEmu issue, not a Cmder issue.

Or it may be due to a console mode program changing the console mode to activate VT100 emulation at the OS level.

See if you can track down what program is used right before the problem begins to occur.

[chrisant996]

@jsmunroe Clink v1.5.1 was published a few minutes ago and clears the ENABLE_VIRTUAL_TERMINAL_INPUT mode even more aggressively than before. Some console programs set it but neglect to clear it, and that's what causes the problem you reported.

Also, some console mode programs continue to run and use their parent's terminal input/output handles even after the parent (e.g. cmd.exe) regains control and shows an input prompt. That's especially problematic for two reasons:

1. They may set ENABLE_VIRTUAL_TERMINAL_INPUT again even after Clink has cleared it multiple times already (especially if a console mode program gets aborted e.g. via Ctrl-C, which can interfere with their ability to restore the console mode if they don't have proper error handling code).
2. They may read from the terminal or write to the terminal, and if either of those happen it interferes with cmd.exe (either cmd.exe will get the input, or the other program will get the input -- not both -- and the input and output get jumbled in that case).

Clink tries its best to compensate for those other buggy programs/scripts, but there is only so much that Clink can do to defend against them.

Ultimately, you need to track down which programs and/or scripts are triggering the problem, and then get them fixed.

[jsmunroe]

I guess it would have to be git since that's what I use most of the time.

[chrisant996]

I guess it would have to be git since that's what I use most of the time.

Seems unlikely. I use git all the time and I've only run into this 3 or 4 times in 2.5 years, and it was definitely with other programs not git.

However, it could potentially be an external tool that's been configured to be spawned by git (e.g. a diff tool or merge tool or etc).

[chrisant996]

... or it's also possible that you're hitting something different that might be purely a ConEmu issue. I don't use ConEmu.

By the way, I'm pretty sure the issue has nothing to do with the Ctrl key getting stuck. It's the ENABLE_VIRTUAL_TERMINAL_INPUT console mode, which is something that can only be changed programmatically. The VT100 escape codes for up, down, right, left are ESC [ A, ESC [ B, ESC [ C, and ESC [ D, respectively.

[daxgames]

That was a long standing bug in comemu that was fixed some time ago and I have not seen it since.

When it was an issue I saw it mostly in vim in a cmd.exe terminal.

[DRSDavidSoft]

I have been trying several scenarios for these past couple of months and can confirm this is not related to the passage of an arbitrary amount of time; additionally it can also happen outside of Cmder and ConEmu. One way I have found to trigger it is to ssh into another host, run certain programs, and then hit Ctrl Break to kill the ssh connection. This will result in the same exact issue.

Currently I don't believe this issue is related to Cmder, it might be relevant to something else. Since it also happens with cmd.exe and conhost.exe (no Clink/ConEmu), I'm investigating to see exactly what is being changed in the terminal that causes this.

[chrisant996]

@DRSDavidSoft it's caused by what I said in this comment.

Some program is changing the console input mode, and not restoring the original console mode before exiting.

[DRSDavidSoft]

@chrisant996 Yeah I assumed that echoing something to the terminal might trigger this while the ENABLE_VIRTUAL_TERMINAL_INPUT flag is set.

Am I correct to assume according to your comment, just by setting the flag this issue can be repro'ed?

[chrisant996]

You're seeing echo'd input, not output.

It's more complicated than just the flag being set. But the flag is what allows the problem to occur.

And the flag is present because a program explicitly forced it on because the program wants to receive emulated VT input, but the program neglected to restore the original flags before exiting. So then other things can accidentally receive emulated VT input when they aren't expecting it.

ConEmu has a built-in option for showing terminal modes in its status bar. You can use ConEmu to watch for what program(s) sets the flag but exits without clearing it.