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

[0xbadfca11]

• 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]

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

[Warblefly]

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]

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

[Warblefly]

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]

@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]

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]

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]

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

TERM=vt100 vi ~/.bashrc

[daiconrad]

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]

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 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]

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]

@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]

@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]

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]

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]

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]

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

2. 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'

3. 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]

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

[warpdesign]

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

[elcct]

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]

@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]

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]

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]

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]

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

[MrObvious]

FWIW adding my $.02 to fast track this.

[arjenpdevries]

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]

Did the fix get delayed to next weeks release?

[rmobis]

Any idea when this will be pushed?

[bitcrazed]

@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 ... and in the first-run distro setup process

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]

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]

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]

On Wed, May 31, 2017 at 10:09 AM, dhorsley notifications@github.com wrote:

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:

​Unfortunately, page up/down keys stop working with this TERM value :-(

I hope very much the fix makes it into the next Insider Build. This is becoming a serious nuisance and is a work-halting regression, here.​

[dhorsley]

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]

@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]

@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]

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/

[simonbuchan]

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]

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

[arjenpdevries]

PS: fixed in today's update!

[zyf0330]

How to update this fix?

[sunilmut]

@zyf0330 - Install Insider build 16215

[AndyGauge]

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

[zyf0330]

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

[AndyGauge]

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

[offero]

I'm observing the same vim.basic hanging behavior now. Keys do not respond in that shell any longer. I can run it in tmux. 1 pane responds while the pane with vim does not.

The crazy part is, I can't figure out how to kill the task. I keep getting access denied errors.

[zadjii-msft]

@offero Considering the initial issue described by this thread was confirmed fixed over a year ago, what you're seeing is almost certainly a new issue. Could you open a new issue on this repo to track and debug what you're seeing now (rather than necro'ing an old thread)?