previous command becomes ‘[A’

[simaek]

Use the arrow keys to call up the previous command, strange characters will appear.
I haven't encountered this problem before. I only discovered it recently. It may be related to the update of windows. I tested it on a colleague's computer and another computer of mine, and it all reappeared.
Below is a screenshot.

It seems that the readline module has a few strange inputs.

[chrisant996]

Please share your .inputrc file.

It sounds like there might be an entry that captures a partial key sequence, throwing off other key sequences. Clink uses a custom terminal input driver, so some extended keys (and particularly Esc) have different escape sequences than usual.

Also, in case this is related: when adding new key sequences, the best way to find out the right escape sequence to use is to runclink echo and then press the desired key.

[chrisant996]

P.S. [A is part of the escape code produced by Up. Somehow the initial escape character is missed.

Also, I'm not able to reproduce this, so can you share any additional information about the configuration or locale or etc?

Please share the clink.log file, too, if possible.

[simaek]

Do you mean this file?

inputrc.txt

I ran clink echo, and pressed the arrow keys and esc key, the results are as follows:

locale:
LANG=zh_CN.UTF-8
LC_CTYPE="zh_CN.UTF-8"
LC_NUMERIC="zh_CN.UTF-8"
LC_TIME="zh_CN.UTF-8"
LC_COLLATE="zh_CN.UTF-8"
LC_MONETARY="zh_CN.UTF-8"
LC_MESSAGES="zh_CN.UTF-8"
LC_ALL=

[chrisant996]

If the inputrc file came from /etc/ that doesn't seem like the one Clink is using.

Use clink info to find which inputrc file Clink is loading (and all the places it searches for them).

That's the one I need to see. Maybe it's the same /etc/ one, but that would be surprising since that isn't a directory that Clink searches unless specially configured to do so.

Also, can you confirm what are the repro steps?
I think the animated image implies that the steps are:

1. type grep press Enter
2. press Up, and observe it activated the previous history entry
3. press Esc, and observe it cleared the input line
4. press Up

EXPECTED: activates the previous history entry.
ACTUAL: the key sequence is mishandled and part of the key sequence ([A) shows up as raw input in the input line.

[simaek]

It seem that no inputrc files are configurated.

Steps:

1. type 'grep' press Enter
2. type Up, display [A

No more other steps.

It seems to appear only when using *NIX commands. e.g. ls, cat, grep. But when using CMD cammands, such as dir, it will activate the previous history entry correctly.

[chrisant996]

Oh! I understand now roughly what's happening, thanks to your use of debug.log_terminal:

1. type grep, press Enter
2. press Up, press Enter
3. press Up

Somehow the initial \e from the Up in step 3 is getting treated as separate input and getting reconverted into a separate press of Esc, so the \e[A gets translated into \e[27;27~[A.

Are you using WSL or cygwin in Cmder? Or anything else other than simply launching cmd.exe? It appears something is intercepting console input and forwarding it (inaccurately), causing Clink to sometimes see the real input stream but sometimes see a preprocessed simulated input stream.

This sounds very similar to this known issue in ConEmu:
ConEmu #1691
Cmder #2488

[chrisant996]

One more question: Does this happen with Clink in a standalone cmd.exe as well? Or only inside Cmder/ConEmu?

[simaek]

Yes, I am using cygwin in Cmder. This is the default startup task of Cmder.
I ran cmd /k ""%ConEmuDir%\..\init.bat" in the native cmd.exe to use Cmder, it did not happen.
You are right, this may caused by ConEmu.

[chrisant996]

Ugh. Ok, I will try to investigate inside ConEmu's source code and see if I can find more details and/or a workaround. That might take a while, though.

[chrisant996]

It seems to appear only when using *NIX commands. e.g. ls, cat, grep. But when using CMD cammands, such as dir, it will activate the previous history entry correctly.

This part is very interesting.

• Where are the *nix commands coming from? E.g. what *nix system do you have installed?
• How do you launch Cmder, and from where? E.g. from the Start menu, or from a bash shell, or another way?

Maybe *nix commands are leaving the console mode set to an unexpected mode, or maybe some ConEmu internal state isn't restored after a *nix command. If we can enable me to reproduce the issue, that will significantly improve the chances of successfully resolving this problem.

Thanks!

[chrisant996]

Yay, I can repro now:

0. Not sure whether this was a necessary step, but I installed Windows Subsystem for Linux and installed Ubuntu.
1. Win+R and c:\wbin\Cmder\Cmder.exe
2. ls
3. Up (must do it quickly after ls -- within about 5 seconds can repro; any longer and the problem won't repro)

Investigating...

UPDATE:

• Waiting 5 or more seconds before pressing Up seems to avoid the problem.
• Clink uses ReadConsoleInputW to get the next input. And the Up results in reading \x1b [A instead of VK_UP as it should. So something is forwarding input to Clink, and doing so inaccurately.
• Presumably ConEmu is intercepting input and forwarding it, and doesn't respond immediately to the *nix command process ending, and continues doing cygwin input translation for a few seconds even though the *nix command has ended.

[chrisant996]

It's the ConEmu "Terminal Mode".

You can observe the terminal mode change by doing this:

• Go to Status Bar in Settings (Settings > Features > Status bar).
• Make sure the "Show status bar" box is checked.
• Add the "Terminal modes" column to the Selected columns.
• Click "Save settings".

Normally there will be a "WK" in the status bar (hover over it to see a description).
When a cygwin program is launched, the terminal mode indicator changes to "XK" when the program is running, and changes back to "WK" about 5 seconds after the program finishes.

In the "XK" mode ConEmu intercepts all keyboard input and converts it to Xterm input. That's what's interfering with Clink (and it will interfere with CMD.exe and some other programs, too).

[chrisant996]

This is ConEmu #2302 and is fixed in ConEmu 210422.

Cmder currently includes ConEmu 210304.

I confirmed that I can't reproduce the problem in the latest ConEmu -- the terminal mode switches back to Windows ("WK") immediately. But I can repro it in older ConEmu versions. The issue was affecting Far and other programs, too.

You can either copy ConEmu 210422 into a Cmder installation, or wait for Cmder to pick up the latest ConEmu, or wait 5 seconds before using extended keys (arrows, Ins, Del, etc) after using a program that requires Xterm mode.