FVim crashes when executing with --wsl flag

[FilBot3]

Using FVim

• https://github.com/yatli/fvim/releases/tag/v0.2-247-g7a2270c

with NeoVim

• https://github.com/neovim/neovim/releases/tag/nightly v0.5.0

I get the following error:

I am running on Windows 10 using Cmder running PowerShell Core 7. I would paste the text, but I can't seem to copy the text out of that window.

[yatli]

Please check the neovim installation in WSL, and ensure nvim is in PATH.

[FilBot3]

I am able to access nvim from my terminal. Still have the same error.

[FilBot3]

Does nvim need to be installed on the WSL side as well?

[yatli]

Yes, a linux version of neovim should be installed on the WSL side. Otherwise, even if you successfully launch the nvim process, it will be a Windows process and you cannot access the WSL functionalities from there.

[FilBot3]

I'm still having issues:

[yatli]

In a wsl term:

echo $PATH which nvim

[FilBot3]

Its technically at the end of the path.

[yatli]

That doesn't look like a conventional installation. For example, I've installed neovim with the unstable PPA and it ends up at /user/bin/nvim. /usr/local/nvim/bin/nvim may not be in the path for a non-interactive session. Do you modify the PATH variable in your .zshrc? I assume you're using oh-my-zsh. The --wsl flag may not pick up the .zshrc, but .bashrc instead, but I'm not sure. Even if for .bashrc, it usually skip the later part of the script if it's non-interactive (check the first few lines)

[FilBot3]

For some reason when I run wsl nvim it doesn't load nvim giving me /bin/bash: nvim: command not found, however when I login to both zsh and bash, I can run nvim. I moved the path modifications to a separate file that both .zshrc and .bashrc load.

So, this seems to be external to FVim, and more of a WSL issue now. WSL is defaulting to Bash, but its not sourcing or loading my .bashrc, .bash_profile or .profile when ran that way. When I run wsl "env" it only shows the paths listed in /etc/profile or those from windows.

[yatli]

Alright. Let's close this issue for now.

[citizen428]

@yatli I'm having a similar issue, but it doesn't seem related to not being able to find nvim.

# WSL2, Ubuntu 20.10, nvim nightly appimage
❯ which nvim
/usr/local/bin/nvim

❯ nvim --version
NVIM v0.5.0-dev+945-gc3b9c3587
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/cc -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/home/runner/work/neovim/neovim/build/config -I/home/runner/work/neovim/neovim/src -I/home/runner/work/neovim/neovim/.deps/usr/include -I/usr/include -I/home/runner/work/neovim/neovim/build/src/nvim/auto -I/home/runner/work/neovim/neovim/build/include
Compiled by runner@fv-az205-349

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "
/home/runner/work/neovim/neovim/build/nvim.AppDir/usr/share/nvim"

Run :checkhealth for more info

# Windows
❯ wsl which nvim
/usr/local/bin/nvim
❯ FVim.exe --wsl

FWIW, VSCode remote also isn't working with this nvim and I can't figure out what changed over the past few days, because FVim was working before.

Please let me know if you'd prefer a separate issue for this.

[yatli]

That looks like a start-up error. I've seen this before when I pass incorrect params to nvim.

Try run nvim directly with wsl and see what happens?

[citizen428]

Sorry, should have mentioned this in my original comment, starting it directly works fine, it drops me into my console nvim (as you can see Powershell tab, but WSL nvim indicated by the Ubuntu icon in the status bar).

[yatli]

the "unexpected byte message" is actually raw text coming from neovim. I guess it really wants to say something now that it doesn't follow the protocol :)

@citizen428 can you try latest head 9697d59 -- I've patched it so that it will print the raw message in the crash dialog on exit, like, if you do fvim --help:

[citizen428]

Thank you @yatli, your hint " I guess it really wants to say something now that it doesn't follow the protocol :)" put me on track for a fix even before trying out the new build: I had a command in my shell init code that didn't redirect its output to /dev/null which caused this behavior. I appreciate you taking the time to help me figure this out, thanks!

[yatli]

noprob, I'm glad you figured it out ;)