starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Console bash incorrectly shows characters as overwritten after using arrow keys #180

New Issue
Closed
opened 2026-01-30 21:44:50 +00:00 by claunia · 7 comments
claunia commented 2026-01-30 21:44:50 +00:00
Owner
Copy Link

Originally created by @cgerdes1 on GitHub (Mar 3, 2018).

Windows version is 10.0.16299.248
Bash is using locale en_US.UTF-8

When i use the Arrow keys to go back on the command line, and start typing, what has previously been written will be overwritten IF I have passed over a space character using the right Arrow key (not expected). If I do not pass over a space character, the new entered characters are instead inserted as new characters and the rest of the existing line is moved forward (expected behaviour).

The buffer itself is not overwritten, so executin the modified command line will actually execute something else than what I see as the command line.

I have no idea why this occurs. Restarting bash does not help. I tested on Another machine, with the same version of Windows and Bash, but without having the same issues.

2018-03-03 19_51_44-uranus__home

Example above:
I write the line "wordbeforespace wordafterspace" and hit enter
Using the up Arrow key I get the line back, I edit the lite using the left Arrow key, inserting the number 1 expecting the line "word1before1space word1after1space" however as the screenshot shows, the first Word instead is shown as "word1efore1pace". However, when I hit enter, the command being executed indeed is the expected "word1before1space".

This almost breaks the entire use of bash for me right now, since I very fast get unsure what command will actually be executed.

Originally created by @cgerdes1 on GitHub (Mar 3, 2018). Windows version is 10.0.16299.248 Bash is using locale en_US.UTF-8 When i use the Arrow keys to go back on the command line, and start typing, what has previously been written will be overwritten IF I have passed over a space character using the right Arrow key (not expected). If I do not pass over a space character, the new entered characters are instead inserted as new characters and the rest of the existing line is moved forward (expected behaviour). The buffer itself is not overwritten, so executin the modified command line will actually execute something else than what I see as the command line. I have no idea why this occurs. Restarting bash does not help. I tested on Another machine, with the same version of Windows and Bash, but without having the same issues. ![2018-03-03 19_51_44-uranus__home](https://user-images.githubusercontent.com/27770842/36938055-5489b52e-1f1c-11e8-83d3-9885d1d0a755.png) Example above: I write the line "wordbeforespace wordafterspace" and hit enter Using the up Arrow key I get the line back, I edit the lite using the left Arrow key, inserting the number 1 expecting the line "word1before1space word1after1space" however as the screenshot shows, the first Word instead is shown as "word1efore1pace". However, when I hit enter, the command being executed indeed is the expected "word1before1space". This almost breaks the entire use of bash for me right now, since I very fast get unsure what command will actually be executed.
claunia added the Product-ConhostIssue-BugArea-VTResolution-Duplicate labels 2026-01-30 21:44:50 +00:00
claunia commented 2026-01-30 21:44:51 +00:00
Author
Owner
Copy Link

@cgerdes1 commented on GitHub (Mar 3, 2018):

After some additional investigation, I found one difference between the 2 boxes I have, were only one of them shows the above behaviour. The one that does not have this issue, was originally installed using lxrun and the bash command in powershell and later upgraded to Fall Creator, the other machine was installed using the "new" way of installing the app from the store after Fall Creators update.

@cgerdes1 commented on GitHub (Mar 3, 2018): After some additional investigation, I found one difference between the 2 boxes I have, were only one of them shows the above behaviour. The one that does not have this issue, was originally installed using lxrun and the bash command in powershell and later upgraded to Fall Creator, the other machine was installed using the "new" way of installing the app from the store after Fall Creators update.
claunia commented 2026-01-30 21:44:51 +00:00
Author
Owner
Copy Link

@cgerdes1 commented on GitHub (Mar 3, 2018):

After even more investigation I found what is causing this. After re-installing the app I no longer had the problem. It did not re-occur until I copied back my original .profile which changed the TERM env variable to be "xterm-color" in order to use the color prompt in .bashrc. This TERM emulation causes the odd behaviour originally described above. The original app after Clean install uses "xterm-256color" as the TERM emulation, which does not have this bug. My second machine uses TERM=xterm and does have this behaviour either.

@cgerdes1 commented on GitHub (Mar 3, 2018): After even more investigation I found what is causing this. After re-installing the app I no longer had the problem. It did not re-occur until I copied back my original .profile which changed the TERM env variable to be "xterm-color" in order to use the color prompt in .bashrc. This TERM emulation causes the odd behaviour originally described above. The original app after Clean install uses "xterm-256color" as the TERM emulation, which does not have this bug. My second machine uses TERM=xterm and does have this behaviour either.
claunia commented 2026-01-30 21:44:51 +00:00
Author
Owner
Copy Link

@cyraid commented on GitHub (May 30, 2018):

This is happening to me currently. SSHing into my web server, then trying to use nano and use the arrow keys (go ahead and hold left for a bit and it'll look like it's overwriting characters and such).

@cyraid commented on GitHub (May 30, 2018): This is happening to me currently. SSHing into my web server, then trying to use nano and use the arrow keys (go ahead and hold left for a bit and it'll look like it's overwriting characters and such).
claunia commented 2026-01-30 21:44:51 +00:00
Author
Owner
Copy Link

@austinv11 commented on GitHub (Jul 10, 2018):

I can replicate @cyraid's issue despite my TERM variable being set to xterm-256color (windows version 10.0.17134.112)

@austinv11 commented on GitHub (Jul 10, 2018): I can replicate @cyraid's issue despite my TERM variable being set to `xterm-256color` (windows version `10.0.17134.112`)
claunia commented 2026-01-30 21:44:51 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Jan 25, 2020):

I was able to reproduce this by setting TERM to xterm-color, and can see in the debugger that it's trying to use Insert-Replace Mode (IRM) to insert the character, and that's something we don't yet support. So this is essentially a dup of #1947 (or vice versa).

@j4james commented on GitHub (Jan 25, 2020): I was able to reproduce this by setting TERM to xterm-color, and can see in the debugger that it's trying to use Insert-Replace Mode (IRM) to insert the character, and that's something we don't yet support. So this is essentially a dup of #1947 (or vice versa).
claunia commented 2026-01-30 21:44:52 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 24, 2020):

Oh hey! I never realized we had this duplicate... even though James totally called it out.

/dup #1947.

@DHowett commented on GitHub (Jun 24, 2020): Oh hey! I never realized we had this duplicate... even though James totally called it out. /dup #1947.
claunia commented 2026-01-30 21:44:52 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jun 24, 2020):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Jun 24, 2020): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-VT Issue-Bug Product-Conhost Resolution-Duplicate
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#180
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?