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

Bug Report: CentOS system ssh cursor behavior bug #2568

New Issue
Closed
opened 2026-01-30 22:58:38 +00:00 by claunia · 13 comments
claunia commented 2026-01-30 22:58:38 +00:00
Owner
Copy Link

Originally created by @tong-qiu on GitHub (Jul 4, 2019).

Originally assigned to: @zadjii-msft on GitHub.

Environment

Windows build number: Microsoft Windows [Version 10.0.18362.207]
Windows Terminal version (if applicable): Version: 0.2.1831.0

Any other software?

Steps to reproduce

  1. ssh to a centOS based system (it has to be a CentOS Linux)
  2. open a Linux screen session
  3. press backspace when there is nothing in the current command line

Expected behavior

Nothing happens

Actual behavior

The location of the changes. The display of the text is weird if you type something.
Similar problem link: https://github.com/microsoft/WSL/issues/1436

Originally created by @tong-qiu on GitHub (Jul 4, 2019). Originally assigned to: @zadjii-msft on GitHub. # Environment ```none Windows build number: Microsoft Windows [Version 10.0.18362.207] Windows Terminal version (if applicable): Version: 0.2.1831.0 Any other software? ``` # Steps to reproduce 1. ssh to a centOS based system (it has to be a CentOS Linux) 2. open a Linux screen session 3. press backspace when there is nothing in the current command line # Expected behavior Nothing happens # Actual behavior The location of the changes. The display of the text is weird if you type something. Similar problem link: https://github.com/microsoft/WSL/issues/1436
claunia commented 2026-01-30 22:58:39 +00:00
Author
Owner
Copy Link

@JohnHolmesII commented on GitHub (Jul 7, 2019):

I am able to confirm this issue. The cursor jumps to the other side of the screen.
image

@JohnHolmesII commented on GitHub (Jul 7, 2019): I am able to confirm this issue. The cursor jumps to the other side of the screen. ![image](https://user-images.githubusercontent.com/8901018/60764614-918f7e80-a07c-11e9-8a77-813fcff36913.png)
claunia commented 2026-01-30 22:58:40 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 8, 2019):

Does this repro with both conhost.exe and Windows Terminal?

While this does look like #283, I'll leave this open to track the new regression since that fix went in.

@zadjii-msft commented on GitHub (Jul 8, 2019): Does this repro with both conhost.exe and Windows Terminal? While this does look like #283, I'll leave this open to track the new regression since that fix went in.
claunia commented 2026-01-30 22:58:40 +00:00
Author
Owner
Copy Link

@JohnHolmesII commented on GitHub (Jul 9, 2019):

It does happen with conhost.exe as well. Might be out of scope here?

@JohnHolmesII commented on GitHub (Jul 9, 2019): It does happen with conhost.exe as well. Might be out of scope here?
claunia commented 2026-01-30 22:58:40 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jul 9, 2019):

It's in scope here! This repository also holds the living source code for conhost.exe. 😄

@DHowett-MSFT commented on GitHub (Jul 9, 2019): It's in scope here! This repository also holds the living source code for conhost.exe. :smile:
claunia commented 2026-01-30 22:58:40 +00:00
Author
Owner
Copy Link

@tong-qiu commented on GitHub (Jul 9, 2019):

PowerShell also has the same problem. The cursor and text display problem can also occur during text editing and running htop.

@tong-qiu commented on GitHub (Jul 9, 2019): PowerShell also has the same problem. The cursor and text display problem can also occur during text editing and running htop.
claunia commented 2026-01-30 22:58:40 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 5, 2019):

Okay so I see what the problem is here.

Looks like when you hit backspace at an empty prompt, we get 3 things:

  1. \x1b[?5h to enable reverse video mode
  2. somewhere in the neighborhood of 400 NULs
  3. \x1b[?5l, to disable reverse video mode

What that means is the default CentOS configuration for screen is using a "visual bell" instead of an audible bell. See this page for screen documentation. You can confirm that this is the source of the problem by entering the command vbell at the screen prompt to toggle the bell state. For me, the console title displayed the following:
image

Curiously, that's not enough to be able to repro this outside of the "ssh into CentOS" scenario. It doesn't repro in the linux terminal that centOS boots into directly. Presumably they're handling the NULs correctly. Even when I manually change the TERM to screen (from screen.linux), it doesn't repro directly in CentOS. I wouldn't expect it to.

I couldn't get this to repro on Ubuntu's screen. Even by setting TERM=screen and enabling visual bell, this doesn't repro. However, the screen I have on CentOS is Screen version 4.01.00devel (GNU) 2-May-06, while the screen on Ubuntu is Screen version 4.06.02 (GNU) 23-Oct-17, with 11 years of patches. So presumably this is something that was changed for the updated screen.

Most of that is a sidebar on the real issue here: the console doesn't eat NUL characters like a terminal might. So when we see all those NULs come in, we move the cursor forward and insert NUL into our buffer. We do this for legacy reasons, because someone out there is presumably actually making use of a NUL in the buffer.

We might be able to fix this. IMO we could probably ignore NUL's when an app has requested ENABLE_VIRTUAL_TERMINAL_PROCESSING. When that flag is set, the app wants to act like a linux application, so we should treat them like one, and ignore those NULs. I'd definitely want @miniksa and @DHowett-MSFT to chime in with their opinion - this might be a breaking change and I don't want my butt to be the only butt on the line.
We've definitely seen this before. There's an internal bug somewhere with the same problem, but I don't think it ever got migrated out, and I think it might have been archived -____-

@zadjii-msft commented on GitHub (Sep 5, 2019): Okay so I see what the problem is here. Looks like when you hit backspace at an empty prompt, we get 3 things: 1. `\x1b[?5h` to enable reverse video mode 2. somewhere in the neighborhood of 400 `NUL`s 3. `\x1b[?5l`, to disable reverse video mode What that means is the default CentOS configuration for `screen` is using a "visual bell" instead of an audible bell. See [this page for `screen` documentation](https://www.gnu.org/software/screen/manual/html_node/Bell.html). You can confirm that this is the source of the problem by entering the command `vbell` at the `screen` prompt to toggle the bell state. For me, the console title displayed the following: ![image](https://user-images.githubusercontent.com/18356694/64359634-62d74b00-cfce-11e9-8cf6-41291ea2a41f.png) Curiously, that's not enough to be able to repro this outside of the "ssh into CentOS" scenario. It doesn't repro in the `linux` terminal that centOS boots into directly. Presumably they're handling the `NUL`s correctly. Even when I manually change the `TERM` to `screen` (from `screen.linux`), it doesn't repro directly in CentOS. I wouldn't expect it to. I couldn't get this to repro on Ubuntu's screen. Even by setting `TERM=screen` and enabling visual bell, this doesn't repro. However, the `screen` I have on CentOS is `Screen version 4.01.00devel (GNU) 2-May-06`, while the `screen` on Ubuntu is `Screen version 4.06.02 (GNU) 23-Oct-17`, with _11 years_ of patches. So presumably this is something that was changed for the updated `screen`. Most of that is a sidebar on the real issue here: the console doesn't eat `NUL` characters like a terminal might. So when we see all those `NUL`s come in, we move the cursor forward and insert `NUL` into our buffer. We do this for legacy reasons, because someone out there is presumably actually making use of a `NUL` in the buffer. We _might_ be able to fix this. IMO we could probably ignore `NUL`'s when an app has requested `ENABLE_VIRTUAL_TERMINAL_PROCESSING`. When that flag is set, the app wants to act like a linux application, so we should treat them like one, and ignore those `NUL`s. I'd definitely want @miniksa and @DHowett-MSFT to chime in with their opinion - this might be a breaking change and I don't want my butt to be the only butt on the line. We've definitely seen this before. There's an internal bug somewhere with the same problem, but I don't think it ever got migrated out, and I think it might have been archived -____-
claunia commented 2026-01-30 22:58:41 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Sep 5, 2019):

As far as I'm concerned, NUL being inserted as a SPC is a legacy Win32 console behavior and shouldn't be propagated to the ENABLE_VIRTUAL_TERMINAL_PROCESSING flag if it messes up the behavior of *NIX applications.

What's the actual stack for that call? Does it drop out of the parser in the ->Write or ->Execute and then hit WriteCharsLegacy and follows the NUL --> SPC route?

@miniksa commented on GitHub (Sep 5, 2019): As far as I'm concerned, `NUL` being inserted as a `SPC` is a legacy Win32 console behavior and shouldn't be propagated to the `ENABLE_VIRTUAL_TERMINAL_PROCESSING` flag if it messes up the behavior of *NIX applications. What's the actual stack for that call? Does it drop out of the parser in the ->Write or ->Execute and then hit `WriteCharsLegacy` and follows the `NUL` --> `SPC` route?
claunia commented 2026-01-30 22:58:41 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Sep 5, 2019):

(I believe whether visual bell is “a thousand NULs” is controlled by termcap/terminfo.)

@DHowett-MSFT commented on GitHub (Sep 5, 2019): (I believe whether visual bell is “a thousand NULs” is controlled by termcap/terminfo.)
claunia commented 2026-01-30 22:58:41 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 5, 2019):

@miniksa I haven't drilled into the call at runtime, but looking through the code it looks like it hits ActionExecute to write the NUL via WriteCharsLegacy. We could maybe even have the OutputStateMachineEngine eat them right there.

@DHowett-MSFT That's what I thought, but I couldn't find the corresponding entry.

This was the infocmp output when ssh'd in and running screen:

screen|VT 100/ANSI X3.64 virtual terminal,
        am, km, mir, msgr, xenl,
        colors#8, cols#80, it#8, lines#24, ncv@, pairs#64,
        acsc=++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
        bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
        clear=\E[H\E[J, cnorm=\E[34h\E[?25h, cr=^M,
        csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
        cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C,
        cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\EM,
        cvvis=\E[34l, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM,
        dl1=\E[M, ed=\E[J, el=\E[K, el1=\E[1K, enacs=\E(B\E)0,
        flash=\Eg, home=\E[H, ht=^I, hts=\EH, ich=\E[%p1%d@,
        il=\E[%p1%dL, il1=\E[L, ind=^J, is2=\E)0, kbs=\177,
        kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
        kdch1=\E[3~, kend=\E[4~, kf1=\EOP, kf10=\E[21~,
        kf11=\E[23~, kf12=\E[24~, kf2=\EOQ, kf3=\EOR, kf4=\EOS,
        kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~,
        khome=\E[1~, kich1=\E[2~, kmous=\E[M, knp=\E[6~, kpp=\E[5~,
        nel=\EE, op=\E[39;49m, rc=\E8, rev=\E[7m, ri=\EM, rmacs=^O,
        rmcup=\E[?1049l, rmir=\E[4l, rmkx=\E[?1l\E>, rmso=\E[23m,
        rmul=\E[24m, rs2=\Ec\E[?1000l\E[?25h, sc=\E7,
        setab=\E[4%p1%dm, setaf=\E[3%p1%dm,
        sgr=\E[0%?%p6%t;1%;%?%p1%t;3%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;m%?%p9%t\016%e\017%;,
        sgr0=\E[m\017, smacs=^N, smcup=\E[?1049h, smir=\E[4h,
        smkx=\E[?1h\E=, smso=\E[3m, smul=\E[4m, tbc=\E[3g,
[asdf@centos-000 ~]$ echo $TERM
screen
[asdf@centos-000 ~]$ stty -a
speed 38400 baud; rows 30; columns 120; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?; swtch = <undef>; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc ixany imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

(collapsible for brevity of the thread)

@zadjii-msft commented on GitHub (Sep 5, 2019): @miniksa I haven't drilled into the call at runtime, but looking through the code it looks like it hits `ActionExecute` to write the `NUL` via WriteCharsLegacy. We could maybe even have the `OutputStateMachineEngine` eat them right there. @DHowett-MSFT That's what I thought, but I couldn't find the corresponding entry. This was the infocmp output when ssh'd in and running screen: <details> ``` screen|VT 100/ANSI X3.64 virtual terminal, am, km, mir, msgr, xenl, colors#8, cols#80, it#8, lines#24, ncv@, pairs#64, acsc=++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~, bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l, clear=\E[H\E[J, cnorm=\E[34h\E[?25h, cr=^M, csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H, cud=\E[%p1%dB, cud1=^J, cuf=\E[%p1%dC, cuf1=\E[C, cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\EM, cvvis=\E[34l, dch=\E[%p1%dP, dch1=\E[P, dl=\E[%p1%dM, dl1=\E[M, ed=\E[J, el=\E[K, el1=\E[1K, enacs=\E(B\E)0, flash=\Eg, home=\E[H, ht=^I, hts=\EH, ich=\E[%p1%d@, il=\E[%p1%dL, il1=\E[L, ind=^J, is2=\E)0, kbs=\177, kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA, kdch1=\E[3~, kend=\E[4~, kf1=\EOP, kf10=\E[21~, kf11=\E[23~, kf12=\E[24~, kf2=\EOQ, kf3=\EOR, kf4=\EOS, kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~, kf9=\E[20~, khome=\E[1~, kich1=\E[2~, kmous=\E[M, knp=\E[6~, kpp=\E[5~, nel=\EE, op=\E[39;49m, rc=\E8, rev=\E[7m, ri=\EM, rmacs=^O, rmcup=\E[?1049l, rmir=\E[4l, rmkx=\E[?1l\E>, rmso=\E[23m, rmul=\E[24m, rs2=\Ec\E[?1000l\E[?25h, sc=\E7, setab=\E[4%p1%dm, setaf=\E[3%p1%dm, sgr=\E[0%?%p6%t;1%;%?%p1%t;3%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;m%?%p9%t\016%e\017%;, sgr0=\E[m\017, smacs=^N, smcup=\E[?1049h, smir=\E[4h, smkx=\E[?1h\E=, smso=\E[3m, smul=\E[4m, tbc=\E[3g, [asdf@centos-000 ~]$ echo $TERM screen [asdf@centos-000 ~]$ stty -a speed 38400 baud; rows 30; columns 120; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc ixany imaxbel -iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke ``` </details> (collapsible for brevity of the thread)
claunia commented 2026-01-30 22:58:41 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Sep 5, 2019):

@zadjii-msft, I like that idea better than adding yet another flag to WriteCharsLegacy or keying off the ENABLE_VIRTUAL_TERMINAL_PROCESSING flag, presuming that we go ahead with this.

@miniksa commented on GitHub (Sep 5, 2019): @zadjii-msft, I like that idea better than adding yet another flag to `WriteCharsLegacy` or keying off the `ENABLE_VIRTUAL_TERMINAL_PROCESSING` flag, presuming that we go ahead with this.
claunia commented 2026-01-30 22:58:41 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Oct 23, 2019):

:tada:This issue was addressed in #3015, which has now been successfully released as Windows Terminal Preview v0.6.2951.0.🎉

Handy links:

@ghost commented on GitHub (Oct 23, 2019): :tada:This issue was addressed in #3015, which has now been successfully released as `Windows Terminal Preview v0.6.2951.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v0.6.2951.0) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)
claunia commented 2026-01-30 22:58:42 +00:00
Author
Owner
Copy Link

@tong-qiu commented on GitHub (Oct 23, 2019):

I confirm the cursor problem has been fixed. Thank you so much.

@tong-qiu commented on GitHub (Oct 23, 2019): I confirm the cursor problem has been fixed. Thank you so much.
claunia commented 2026-01-30 22:58:42 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Oct 23, 2019):

That's great news! This will also come out through the insider channel to the normal console window.

@DHowett-MSFT commented on GitHub (Oct 23, 2019): That's great news! This will also come out through the insider channel to the normal console window.
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 Priority-2 Product-Conhost Resolution-Fix-Committed
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#2568
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?