New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WSL - ZSH - Deleting characters does not function as expected #1615

Closed
shughes-uk opened this Issue Jun 21, 2018 · 17 comments

Comments

Projects
6 participants
@shughes-uk

shughes-uk commented Jun 21, 2018

Versions

ConEmu build: 180617 x64
OS version: Windows Build 17692 (Insider build)
shell version : WSL ZSH

Problem description

When I delete characters, it'll skip over the character and delete the character before. Editing files with nano/vi is all kinds of messed up too (looks fine till you start editing).

screenshot 3
screenshot 4
screenshot 5
connector-19580-out.log

I have confirmed this issue is specific to ZSH and does not occur with bash.
It doesn't appear to be anything WSL is doing as hyper terminal works fine for this.

@christinaa

This comment has been minimized.

christinaa commented Jun 23, 2018

Same issue, only occurs in zsh, even after getting rid of double-width characters in $PS1.

capture

This happened after typing testtest and pressing backspace once. Windows build 17686, ConEmu version: 180617 (x64) Preview.

Unable to reproduce when running under directly under wsl.exe, issue only occurs when using the connector. Arrow keys work fine, text editing in vim isn't affected. Using bash for now with a colored prompt, no issues at all.

@Maximus5

This comment has been minimized.

Owner

Maximus5 commented Jun 24, 2018

@christinaa Same questions. How do you run zsh? Version of Windows? And I need log files from connector.

I can't check insider builds now, but I see no problems in the Win10 stable.

@Maximus5 Maximus5 added this to To Do in Inspection via automation Jun 24, 2018

@christinaa

This comment has been minimized.

christinaa commented Jun 24, 2018

@Maximus5 Tried several ways including -l from the connector and running zsh from .bashrc (I use the ancient original WSL distro on which chsh doesn't work). I posted my Windows version above (10.0.17686.1003 on x86_64).

If I run zsh from bash I get this issue but it goes away when I exit zsh. Output log shows that ZSH outputs a <BS><space><BS> which is what puts the cursor in this weird state.

00000260  65 43 61 63 68 65 20 1b  5b 33 33 6d 3e 20 1b 5b  |eCache .[33m> .[|
00000270  30 30 6d 1b 5b 4b 1b 5b  3f 31 68 1b 3d 1b 5b 3f  |00m.[K.[?1h.=.[?|
00000280  32 30 30 34 68 4f 08 4f  4e 45 54 57 4f 54 48 52  |2004hO.ONETWOTHR|
00000290  45 45 08 20 08                                    |EE. .|

The behavior is odd and is and is probably the fault of oh-my-zsh stuff but that shouldn't leave the cursor where it is visually, because there's a space in between the <BS> control characters.

gfdgdfgdf

Input is just sending a <DEL> (0x7F), I tried using either ^H or ^? (default backspace sequence), both produce the same weird behavior, it seems the bug may be specifically related to some odd interaction between the three characters sent to output:

00000330  62 79 74 65 73 0a 69 6e  70 75 74 3a 20 4b 65 79  |bytes.input: Key|
00000340  55 70 3d 38 32 20 73 6b  69 70 70 65 64 0a 69 6e  |Up=82 skipped.in|
00000350  70 75 74 3a 20 4b 65 79  55 70 3d 36 39 20 73 6b  |put: KeyUp=69 sk|
00000360  69 70 70 65 64 0a 69 6e  70 75 74 3a 20 60 45 60  |ipped.input: `E`|
00000370  20 77 72 69 74 74 65 6e  20 31 20 6f 66 20 31 20  | written 1 of 1 |
00000380  62 79 74 65 73 0a 69 6e  70 75 74 3a 20 4b 65 79  |bytes.input: Key|
00000390  55 70 3d 36 39 20 73 6b  69 70 70 65 64 0a 69 6e  |Up=69 skipped.in|
000003a0  70 75 74 3a 20 4b 65 79  55 70 3d 31 36 20 73 6b  |put: KeyUp=16 sk|
000003b0  69 70 70 65 64 0a 69 6e  70 75 74 3a 20 60 7f 60  |ipped.input: `.`|
000003c0  20 77 72 69 74 74 65 6e  20 31 20 6f 66 20 31 20  | written 1 of 1 |
000003d0  62 79 74 65 73 0a 69 6e  70 75 74 3a 20 4b 65 79  |bytes.input: Key|
000003e0  55 70 3d 38 20 73 6b 69  70 70 65 64 0a 69 6e 70  |Up=8 skipped.inp|
000003f0  75 74 3a 20 65 76 65 6e  74 20 32 20 72 65 63 65  |ut: event 2 rece|

Raw logs:

input.txt
output.txt

Relevant env vars:

SHELL=/bin/bash
SHLVL=4
TERM=xterm-256color

stty

stty -a
speed 38400 baud; rows 80; columns 173; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;discard = ^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 -flusho -extproc
@Maximus5

This comment has been minimized.

Owner

Maximus5 commented Jun 25, 2018

That is unfortunately Windows 10 bug.

Writing to console output the sequence \b \b no more proceses expected result, the cursor is moved left twice.

Stable - ok
win10-17134

Insider - broken
win10-17686

/cc @miniksa

@miniksa

This comment has been minimized.

miniksa commented Jun 25, 2018

@zadjii-msft, can you look at this?

Maximus5 added a commit that referenced this issue Jun 26, 2018

@Maximus5

This comment has been minimized.

Owner

Maximus5 commented Jun 27, 2018

Just checked Win10 build 17692, the bug still there. But I created a workaround in ConEmu build 180626.

2018-06-27_13-53-51

Interestingly, wsl/zsh started in native conhost window does not suffer from BS problem. Only applications which call WinApi get wrong cursor position.

@Maximus5

This comment has been minimized.

Owner

Maximus5 commented Jun 27, 2018

Interestingly that separate calls provide correct cursor position

	WriteConsoleW(hOut, L"\b", 1, &n, nullptr);
	WriteConsoleW(hOut, L" ", 1, &n, nullptr);
	WriteConsoleW(hOut, L"\b", 1, &n, nullptr);

and only write three characters at once get us to wrong result

	WriteConsoleW(hOut, L"\b \b", 3, &n, nullptr);
@christinaa

This comment has been minimized.

christinaa commented Jun 27, 2018

Thank you for the temporary fix, not sure why ZSH does this in the first place (it seems to happen with the default ZSH profile too), something terminfo related likely but that's how it operates on Linux so even though it's weird, that's for ZSH developers to look into or maybe there's a reason for it.

Anyway hopefully this gets fixed at the Win Console level.

@Maximus5

This comment has been minimized.

Owner

Maximus5 commented Jun 27, 2018

There is nothing to fix in zsh. And as I've mentioned, native wsl window works properly.

@zadjii-msft

This comment has been minimized.

zadjii-msft commented Jul 2, 2018

I've filed a bug internally to look into this. Seems odd that the two different styles of writing "\b \b" would affect anything, but I know we did tangentially touch the code responsible for that handling this release so I'll take a look.

@zadjii-msft

This comment has been minimized.

zadjii-msft commented Jul 6, 2018

Woo, this was a doozy. While refactoring, a pair of if statements got collapsed into one, causing us to backspace twice. I'm sending out a PR to fix this now, should be fixed soon enough, and out to insiders a few weeks after that.

Thanks everyone! Especially @Maximus5 for giving me a really easy unit test :)

@chris-downs

This comment has been minimized.

chris-downs commented Oct 9, 2018

@zadjii-msft has this fix been integrated? I'm running into it when running zsh with a multiline prompt inside of tmux on Pro Insider Version 10.0.18252 Build 18252.

@zadjii-msft

This comment has been minimized.

zadjii-msft commented Oct 9, 2018

I believe it should be. @DHowett-MSFT, can you check if this repros?

@zadjii-msft

This comment has been minimized.

zadjii-msft commented Oct 9, 2018

@chris-downs Dustin and I just played with this a bunch in his office and we couldn't get anything like it to repro. Could you file a new issue with repro steps in Microsoft/Console?

@chris-downs

This comment has been minimized.

chris-downs commented Oct 9, 2018

Apologies, I didn't mention that this is happening in ConEmu (v180626 preview) (I ended up here from #1609). I tested from cmd.exe and everything works properly. @Maximus5 are you able to repro? Let me know if you need anything.

@chris-downs

This comment has been minimized.

chris-downs commented Oct 9, 2018

#1609 seems like a better place to continue discussion on this, ill move there.

@Maximus5

This comment has been minimized.

Owner

Maximus5 commented Oct 9, 2018

@chris-downs What issue are you talking about? Workaround for this one was implemented in ConEmu three months ago

@Maximus5 Maximus5 closed this Oct 9, 2018

Inspection automation moved this from To Do to Done Oct 9, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment