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

vi/vim.basic does not responds to keyboard input. #2092

Closed
0xbadfca11 opened this Issue May 12, 2017 · 46 comments

Comments

Projects
None yet
@0xbadfca11

0xbadfca11 commented May 12, 2017

  • Your Windows build number: (Type ver at a Windows Command Prompt)
    16193
    Does not occur in 15063 and 16188.

  • What you're doing and what's happening: (Copy&paste specific commands and their output, or include screen shots)
    Launch vi does immediately hang. no longer responds.
    If killed vi process, returned terminal will not responds.
    But, react to kill -HUP.
    Does not occur using vim.tiny or vi -u NONE.

  • What's wrong / what should be happening instead:
    Can edit file.

  • Strace of the failing command, if applicable: (If <cmd> is failing, then run strace -o strace.txt -ff <cmd>, and post the strace.txt output here)
    https://gist.github.com/0xbadfca11/00a1efe36b690dc1927fd844355a125e/raw/e1c50b41c59f594ab557ebb1ae73736e05366f08/strace.txt

@zadjii-msft

This comment has been minimized.

Member

zadjii-msft commented May 12, 2017

Don't worry, we already have for this committed and on it's way up :)

@Warblefly

This comment has been minimized.

Warblefly commented May 12, 2017

Yep, that's just caught me out. No worries... any idea how long before the next flight? I could do with a day away from coding :-)

@zadjii-msft

This comment has been minimized.

Member

zadjii-msft commented May 12, 2017

@Warblefly unfortunately there's basically no way for me to predict how long it'll take the code to get out, sorry.

@Warblefly

This comment has been minimized.

Warblefly commented May 12, 2017

Fair enough. I understand the release schedule is decided elsewhere. Just so you and the team know, I use this subsystem every day for compiling lots of code, and its output is a vital part of my work at a major British university. The compilation still works and I can use another editor beside vim for now. It'll be nice when it's back.

@sunilmut

This comment has been minimized.

Member

sunilmut commented May 12, 2017

@Warblefly - First, let me acknowledge that breaking vi is something that we are definitely not proud of. We understand the pain. The issue is fixed internally in our dev branch and we would like to fast-track it. But, we can use your and others help with that. If more people want the fix faster, its easier for us to justify the fast-track. So, if this is important to you and anyone else, please chime in here.

We are always happy to hear when someone tells us that WSL is useful within the education industry. And, we are glad you can use this as your daily driver.

@Warblefly

This comment has been minimized.

Warblefly commented May 13, 2017

True. I try to take things lightly, but vim is my standard editor for a lot of professional work in and out of university. To have it not working is going to affect development seriously. I hope you can let the release people know that. Are there any workarounds, other than disabling all the vim features I use every day?

@Warblefly

This comment has been minimized.

Warblefly commented May 13, 2017

I have a workaround because this bug has, unfortunately, become mission-critical this morning.

Use sshd.

  1. Start your Bash shell on Ubuntu under Windows as normal.
  2. Make the privilege separation directory for sshd:
    sudo mkdir /var/run/sshd
  3. Control its permissions:
    sudo chmod 0755 /var/run/sshd
  4. If you're willing to use password authentication instead of public/private key, edit /etc/ssh/sshd_config to allow this (use the pico editor to change PasswordAuthentication from no to yes)
  5. Start sshd:
    sudo start-stop-daemon --start --pidfile /var/run/sshd.pid --exec /usr/sbin/sshd -- -p 22

Now use something like PuTTY to log into localhost (127.0.0.1) and Vim, in all its colours, works. For the complete experience, change your PuTTY font to 'Consolas'.

You will need to login with your Ubuntu on Windows username and password (i.e. the password with which you set-up Ubuntu on Windows when you first installed it). You did make a note of that password, didn't you?

Bizarrely, the console as displayed by PuTTY.exe feels more responsive than the native console window.

@aledell

This comment has been minimized.

aledell commented May 13, 2017

If you don't need fancy terminal features, setting TERM to something like vt100 works. E.g.:

TERM=vt100 vi ~/.bashrc

@daiconrad

This comment has been minimized.

daiconrad commented May 14, 2017

If more people want the fix faster, its easier for us to justify the fast-track. So, if this is important to you and anyone else, please chime in here.

Consider this me chiming in, although I'm very grateful to @aledell for the workaround or else I'd be using ed or (gasp!) emacs.

@djensen47

This comment has been minimized.

djensen47 commented May 14, 2017

If more people want the fix faster, its easier for us to justify the fast-track. So, if this is important to you and anyone else, please chime in here.

Breaking the default editor should be enough to fast track, no? Anybody using git is likely experiencing this issue. (Maybe the devs on the MSFT team understand the importance but management has other metrics about the "importance" of a fix?)

Anyway, this is my +1 to please fast track this fix.

Also, another work around is to use nano (if emacs is out of the question). 😄

@nickperry

This comment has been minimized.

nickperry commented May 14, 2017

This is very disappointing and is causing me significant inconvenience. I am always trying to evangelise WSL and this bug doesn't help the cause. Getting the fix out quickly is paramount.

@warpdesign

This comment has been minimized.

warpdesign commented May 15, 2017

Could this be related to console changes (and not specifically bash) in latest insider build (16193) ?

Since latest Windows insider build, vim doesn't work anymore. Under bash it hangs like described here, and when ran under normal CMD prompt, display gets empty and it seems to hang too (but I cannot see because display is empty).

This did not happen with previous builds.

@zadjii-msft

This comment has been minimized.

Member

zadjii-msft commented May 15, 2017

@warpdesign Yes this is a console change that broke this. We had a pretty high code delta that this bug was introduced in. These kinds of issues are expected with Insider's builds.

I'm not positive that this will work, but based on what the fix for this bug was, it might be possible to get around this bug:

I believe that if you immediately start hitting a key on the keyboard after launching vi (eg, spamming 'enter'), then you'll avoid the bug case, and vi will work normally. It might not work on faster (normal) PC's, but it does work on my VMs. The key is to have some input in the input queue as vi is launching.

@warpdesign

This comment has been minimized.

warpdesign commented May 15, 2017

@zadjii-msft Thanks for the wordaround. I found out that any app using the console (like VSCode) is also impacted by the bug. For now I found that checking "use legacy mode" in the prompt window fixes the problem in both cmd.exe and any app using the concole like VSCode (but it prevents the use of bash).

I hope this bug will get fixed quickly.

@mariusei

This comment has been minimized.

mariusei commented May 15, 2017

PhD student in astrophysics chiming in!

Even though half of my work goes over SSH, eg. running simulations on supercomputers, vim is essential to get the other half of the work done: writing papers.

I found the suggestion of @aledell to work well:
echo "export TERM=vt100" >> ~/.bashrc

@JoBrad

This comment has been minimized.

JoBrad commented May 15, 2017

Found this after a lot of head-banging (including removing and reinstalling WSL). I'm using an alias to workaround this (alias v='TERM=vt100 vim' - Thanks @aledell!). Would love for this to get bumped up in priority. I'm not looking forward to using emacs for a while. 😆

@noelbundick

This comment has been minimized.

Member

noelbundick commented May 16, 2017

Chiming in for the fast-track request. I can live with the TERM workaround or using nano for the time being to touch files. Where this bites me is that with vim as the default editor, I'm hitting this as other programs (today it's kubectl) invoke it for editing & those are ignoring my hacks :)

@djensen47

This comment has been minimized.

djensen47 commented May 16, 2017

Here is a convenient summary of the workarounds. You can do this on the command line or update your ~/.bashrc

  1. Set the TERM to vt100 by @aledell
export TERM=vt100
  1. Create an alias for vim by @JoBrad

Do this if you don't want to universally set the TERM to vt100.

alias v='TERM=vt100 vim'
  1. Set your default editor to something else or set the TERM env var to vt100
export EDITOR=nano
# or...
export EDITOR='TERM=vt100 vim'
@sunilmut

This comment has been minimized.

Member

sunilmut commented May 17, 2017

@ALL - Thanks all for chiming in. With your support, the bug has been approved for fast-track.

@warpdesign

This comment has been minimized.

warpdesign commented May 17, 2017

@sunilmut Great! What does fast-track exactly mean? Can we expect a fix in the next insider build?

@elcct

This comment has been minimized.

elcct commented May 17, 2017

I hope this will be sooner than later, because I might go back to Linux over the weekend. This bug is really frustrating.

@zadjii-msft

This comment has been minimized.

Member

zadjii-msft commented May 17, 2017

@warpdesign If all goes according to plan, it'll likely be in next week's Insider fast-ring build. That's as fast as it can move up and out.

@benkevan

This comment has been minimized.

benkevan commented May 18, 2017

For those complaining, DO NOT USE FAST RING IF YOU'RE UNWILLING TO SUFFER SOME CONSEQUENCES!!!!

I look forward to this getting fast tracked.

I simply changes my term via an alias to get around it. Used nano for a bit too.

Good job Microsoft. Keep it up.

@warpdesign

This comment has been minimized.

warpdesign commented May 18, 2017

I have installed build 16199 from yesterday and unfortunately the problem with vim is still there: the moment vi is ran, display gets empty & it locks.

Back to legacy mode again ;)

@mdavidsen

This comment has been minimized.

mdavidsen commented May 18, 2017

Running on fast-ring this is something we should expect. But is there any change to get this fix via WU? I do understand that it might be a dependency hell to get it work (resulting basically in a new insider-build), but i would be nice not having to wait for the next insider release to fast, since it obviously did not hit in 16199.

Anyway, keep up the good work :-)

@jbaribeault

This comment has been minimized.

jbaribeault commented May 18, 2017

Running through the MinTTY/wslbridge doesn't have this problem either - simpler workaround than enabling SSH...

@MrObvious

This comment has been minimized.

MrObvious commented May 23, 2017

FWIW adding my $.02 to fast track this.

@arjenpdevries

This comment has been minimized.

arjenpdevries commented May 24, 2017

The problem is indeed related to any xterm related TERM variable.

I am on Microsoft Windows [Version 10.0.16199.1000] from an update today, and it is not yet fixed.

Instead of aliasing vi, you can also update ${HOME}/.vimrc with the following line:

set term=vt100
@RobRoseKnows

This comment has been minimized.

RobRoseKnows commented May 25, 2017

Did the fix get delayed to next weeks release?

@rmobis

This comment has been minimized.

rmobis commented May 25, 2017

Any idea when this will be pushed?

@bitcrazed

This comment has been minimized.

Collaborator

bitcrazed commented May 26, 2017

@nickperry @Warblefly @mdavidsen & others: A polite notice:

I appreciate that this issue is a significant impediment at best, and a major PITA at worst, but I would like to point out that:

  1. As was pointed out above, this issue has been fixed.
  2. The fix is bubbling up our build tree and will emerge into insiders builds ~3 weeks after the fix is checked-in. Hopefully, it'll be in the next fast-ring insiders build.
  3. We try to deliver fast-ring insiders builds most weeks.
  4. We do not service Insiders builds via Windows Update since that's actually a slower process than delivering fast-ring builds, due to WU's additional scrutiny & process overhead.

Also, its important to understand the following:

  1. Fast-ring Insiders builds are ~weekly snapshots of Windows as it is being built and, as such, the occasional issue/error will escape, despite our considerable efforts to not break users while we develop the next version of Windows. This is the cost you accept while signing-up for fast-ring updates.
  2. WSL itself is a beta feature, as clearly stated both in the optional components dialog
    image
    ... and in the first-run distro setup process
    image

If you can tolerate a smaller amount of disruption, please adjust your settings to subscribe to slow-ring updates where fewer issues will appear.

If you cannot tolerate even a small amount of disruption, please do not use Insider builds: Fully released versions of Windows are likely your best option.

Thanks everyone for your support: Your bug reports and feedback is enormously valuable, but we do ask for a little patience and understanding as we progress through each release cycle.

@simonbuchan

This comment has been minimized.

simonbuchan commented May 29, 2017

Another workaround which doesn't loose all the syntax highlighting, screen switching, etc., goodies is to switch to neovim - note you should copy / link your ~/.vimrc to .config/nvim/init.vim, and configure git, $EDITOR etc, to use nvim instead of vim.

@bitcrazed I believe this is actually a console bug (Git bash hangs the same way for me), not a WSL bug, thus the fact that WSL is in beta is not relevant :) - but yes, your general point is valid. Part of the problem is that workflow-breaking bugs like this are fairly rare, (Ctrl-C breaking is the only one bigger at least for this for this crowd I can remember, the 100% CPU bug not nearly as big - pretty good for 2 years of fast-paced builds) and slow ring builds are very slow, perhaps a 3-5 a release? Presumably the windows build team has lots of improvements to this they would like to do but are not worth the engineering effort, just like every other team :)

@dhorsley

This comment has been minimized.

dhorsley commented May 31, 2017

Other terminal capability files may work better, if people are still having this issue.

I set my terminal to pcansi-43 and vi(m) is fine. I.e., in ~/.bashrc:

export TERM=pcansi-43

This should still support colour output for syntax highlighting.

@Warblefly

This comment has been minimized.

Warblefly commented May 31, 2017

@dhorsley

This comment has been minimized.

dhorsley commented May 31, 2017

Yes, even with workarounds (I generally use hjkl for movement in vi) you would still have other issues around pass-through of environmental variables. For example, using ssh from a 'worked-around' terminal, may pass on your new TERM setting to a remote workstation which doesn't understand the Windows/PC-compatible settings you had to use manually.

Either way, it needs a fix sooner rather than later. UoW is a pretty great facility, and has already helped free up resources on plenty of sysadmin and developer machines where I work with no real need any more to spin up a VM except for testing something environment-specific. It would be a shame to have to take a step back from that over what I am guessing is most likely a very small bug fix in the console.

@djensen47

This comment has been minimized.

djensen47 commented Jun 7, 2017

@sunilmut 21 days ago:
@ALL - Thanks all for chiming in. With your support, the bug has been approved for fast-track.

3 weeks and counting. 😞

@sunilmut

This comment has been minimized.

Member

sunilmut commented Jun 7, 2017

@djensen47 - It should be fixed in the next release. Sometimes things do get held up for reasons outside our direct control. Apologize for the delay and the inconvenience caused. And, thanks for your patience.

@0xbadfca11

This comment has been minimized.

0xbadfca11 commented Jun 9, 2017

We fixed an issue resulting in VIM being broken for Windows Subsystem for Linux (WSL) users in result flights.
https://blogs.windows.com/windowsexperience/2017/06/08/announcing-windows-10-insider-preview-build-16215-pc-build-15222-mobile/

@0xbadfca11 0xbadfca11 closed this Jun 9, 2017

@simonbuchan

This comment has been minimized.

simonbuchan commented Jun 9, 2017

Note, This build also fixes the same issue I had opening Git for Windows bash, it seems like it was a conhost.exe bug, not WSL specific, maybe?

@sunilmut

This comment has been minimized.

Member

sunilmut commented Jun 9, 2017

@simonbuchan - Yes, it was a conhost bug, not WSL specific.

@arjenpdevries

This comment has been minimized.

arjenpdevries commented Jun 12, 2017

PS: fixed in today's update!

@zyf0330

This comment has been minimized.

zyf0330 commented Jun 13, 2017

How to update this fix?

@sunilmut

This comment has been minimized.

Member

sunilmut commented Jun 13, 2017

@zyf0330 - Install Insider build 16215

@AndyGauge

This comment has been minimized.

AndyGauge commented Jun 16, 2017

Was so looking forward to this, but 16215 broke my start menu. Thanks for the workaround @aledell

@zyf0330

This comment has been minimized.

zyf0330 commented Jun 28, 2017

@AndyGauge I see that newest version in insider is 16193, so where did you get it?

@AndyGauge

This comment has been minimized.

AndyGauge commented Jun 28, 2017

@zyf0330 I rolled back to 16199.1000 delivered through fast ring Windows Insider Program. Looks like 16226 wants to install today.

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