Running Neovim in Vim's terminal triggers E5009 (uses Vim's VIM/VIMRUNTIME) #8696

blueyed · 2018-07-06T17:54:54Z

Vim appears to set $VIM and $VIMRUNTIME in its terminal environment, which then gets picked up by Neovim.

Running :checkhealth will trigger:

E5009: Invalid $VIMRUNTIME: /usr/share/vim/vim81

The workaround is to unset VIM/VIMRUNTIME before running nvim.

Vim 8.1.22
NVIM v0.3.1-139-g2bfabd5b

The text was updated successfully, but these errors were encountered:

blueyed · 2018-07-06T17:58:50Z

Vim behaves the same (it also uses an existing $VIM/VIMRUNTIME from Neovim's terminal), but there has('python3') still works.

Not sure if anything can be improved here really - feel free to close it.

justinmk · 2018-07-06T18:12:40Z

Yeah, this is a pain point for me. We need to undefine VIMRUNTIME, NVIM_LISTEN_ADDRESS, etc. in :terminal. Been waiting on #7202 but maybe we can do something else in the meantime.

justinmk · 2018-07-06T18:14:04Z

Oops I got your report mixed up. I thought Vim already undefined VIMRUNTIME in its :terminal. There's not really anything we can do about Vim's :terminal ....

blueyed · 2018-07-06T19:18:34Z

undefine VIMRUNTIME, NVIM_LISTEN_ADDRESS, etc.

Maybe it would be better to not pick it up during startup?
It might be useful to see if there is an outer (Neo)vim after all.
Maybe VIMRUNTIME could be unset, but not VIM or something in this direction - or another new environment variable could be set to indicate that this is :terminal?

I came across this when trying to improve vim-tmux-navigator when used nested (via christoomey/vim-tmux-navigator#201). But there appears to be no autocommand for when an inner Neovim is entered it seems. Maybe FocusGained (should) get(s) triggered?! (i.e. the outer Neovim should send the escape sequences when entering/leaving a terminal window?! (if focus reporting is enabled)

janlazo · 2018-07-06T19:22:20Z

@blueyed Did you try detecting VIM_SERVERNAME?

jamessan · 2018-07-06T19:25:34Z

Vim added a $VIM_TERMINAL environment variable (c.f., 8.1.0049 and 8.1.0050) so programs can know when they're running inside a vim :terminal.

jamessan · 2018-07-06T19:27:11Z

We need to undefine VIMRUNTIME, NVIM_LISTEN_ADDRESS, etc. in :terminal

Then how would programs in :terminal communicate back to their containing nvim (like page does)?

aspieln3r · 2020-04-10T05:41:13Z

I would like to work on this issue.
The solution seems to be checking for $VIM_TERMINAL and then if set, unset $VIM and $VIMRUNTIME.
Can someone guide me from here?

drosan-dev · 2020-08-15T18:55:48Z

I unset VIM VIMRUNTIME when nvim start

drosan-dev · 2020-08-15T18:59:27Z

#12759

shinymimiq · 2021-06-17T03:12:09Z

unset VIM and VIMRUNTIME will still cause problem when call :checkhealth in Nvim inside of vim terminal because we need valid VIM and VIMRUNTIME for :checkhealth

What about we handle this special case inside our vim_getenv function.
We can check if we are trying to get VIMRUNTIME or VIM inside of vim terminal, if so, we should assume those are empty and set them as we do normally.
e.g #14838

jamessan · 2021-06-19T02:29:26Z

We can check if we are trying to get VIMRUNTIME or VIM inside of vim terminal, if so, we should assume those are empty and set them as we do normally.

What if I'm trying to run against a custom runtime from with a vim terminal? VIMRUNTIME=... nvim foo would be the typical way to do that, but you're suggesting to just ignore the explicitly set VIMRUNTIME because VIM_TERMINAL is set?

There are really two problems here.

nvim stuck with the same environment variables Vim uses.
Both programs export VIM/VIMRUNTIME to the environments of their child processes

I don't recall (and don't feel like looking right now) whether the latter point has been discussed for Vim. However, it seems those two variables should not be exported into child processes. Then we would know for sure that if they're set, it's because the user did so.

VIM_SERVERNAME/NVIM_LISTEN_ADDRESS should still be exported to child processes, since that allows communicating with the containing process (including querying them for their VIMRUNTIME if needed).

clason · 2021-12-15T10:31:49Z

Duplicate of #6764, so I'm closing this one. (Feel free to reopen and close the other one instead.)

zeertzjq · 2021-12-15T10:35:25Z

No, this is not a duplicate. This is about running Nvim in Vim's terminal, that one is about running Vim in Nvim's terminal.

clason · 2021-12-15T10:37:48Z

Whoops! Only consolation is that Justin made the same mistake (#8696 (comment)) 😄

PROBLEM ------------------------------------------------------------------------ $NVIM_LISTEN_ADDRESS has conflicting purposes as both a parameter ("the current process should listen on this address") and a descriptor ("the current process is a child of this address"). This contradiction means the presence of NVIM_LISTEN_ADDRESS is ambiguous, so child Nvim always tries to listen on its _parent's_ socket. This is the cause of lots of "Failed to start server" spam in our test/CI logs: WARN 2022-04-30… server_start:154: Failed to start server: address already in use: \\.\pipe\nvim-4480-0 WARN 2022-04-30… server_start:154: Failed to start server: address already in use: \\.\pipe\nvim-2168-0 SOLUTION ------------------------------------------------------------------------ 1. Set $NVIM to v:servername, *only* in child processes. - Now the correct way to detect a "host" or "parent" Nvim is to check for $NVIM env var. 2. Do NOT set $NVIM_LISTEN_ADDRESS child processes. 3. On startup if $NVIM_LISTEN_ADDRESS exists, unset it immediately after server init. 4. Open a channel to parent automatically, expose it as v:parent. This also fixes the "Failed to start server" spam in our test/CI logs: WARN 2022-04-30… server_start:154: Failed to start server: address already in use: \\.\pipe\nvim-4480-0 WARN 2022-04-30… server_start:154: Failed to start server: address already in use: \\.\pipe\nvim-2168-0 Fixes neovim#3118 Fixes neovim#6764 Fixes neovim#9336 Ref neovim#8247 (comment) Ref neovim#8696

PROBLEM ------------------------------------------------------------------------ $NVIM_LISTEN_ADDRESS has conflicting purposes as both a parameter ("the current process should listen on this address") and a descriptor ("the current process is a child of this address"). This contradiction means the presence of NVIM_LISTEN_ADDRESS is ambiguous, so child Nvim always tries to listen on its _parent's_ socket. This is the cause of lots of "Failed to start server" spam in our test/CI logs: WARN 2022-04-30… server_start:154: Failed to start server: address already in use: \\.\pipe\nvim-4480-0 WARN 2022-04-30… server_start:154: Failed to start server: address already in use: \\.\pipe\nvim-2168-0 SOLUTION ------------------------------------------------------------------------ 1. Set $NVIM to v:servername, *only* in child processes. - Now the correct way to detect a "host" or "parent" Nvim is to check for $NVIM env var. 2. Do NOT set $NVIM_LISTEN_ADDRESS child processes. 3. On startup if $NVIM_LISTEN_ADDRESS exists, unset it immediately after server init. 4. Open a channel to parent automatically, expose it as v:parent. Fixes neovim#3118 Fixes neovim#6764 Fixes neovim#9336 Ref neovim#8247 (comment) Ref neovim#8696

PROBLEM ------------------------------------------------------------------------ $NVIM_LISTEN_ADDRESS has conflicting purposes as both a parameter ("the current process should listen on this address") and a descriptor ("the current process is a child of this address"). This contradiction means the presence of NVIM_LISTEN_ADDRESS is ambiguous, so child Nvim always tries to listen on its _parent's_ socket. This is the cause of lots of "Failed to start server" spam in our test/CI logs: WARN 2022-04-30… server_start:154: Failed to start server: address already in use: \\.\pipe\nvim-4480-0 WARN 2022-04-30… server_start:154: Failed to start server: address already in use: \\.\pipe\nvim-2168-0 SOLUTION ------------------------------------------------------------------------ 1. Set $NVIM to the parent v:servername, *only* in child processes. - Now the correct way to detect a "parent" Nvim is to check for $NVIM. 2. Do NOT set $NVIM_LISTEN_ADDRESS in child processes. 3. On startup if $NVIM_LISTEN_ADDRESS exists, unset it immediately after server init. 4. Open a channel to parent automatically, expose it as v:parent. Fixes neovim#3118 Fixes neovim#6764 Fixes neovim#9336 Ref neovim#8247 (comment) Ref neovim#8696

PROBLEM ------------------------------------------------------------------------ $NVIM_LISTEN_ADDRESS has conflicting purposes as both a parameter ("the current process should listen on this address") and a descriptor ("the current process is a child of this address"). This contradiction means the presence of NVIM_LISTEN_ADDRESS is ambiguous, so child Nvim always tries to listen on its _parent's_ socket. This is the cause of lots of "Failed to start server" spam in our test/CI logs: WARN 2022-04-30… server_start:154: Failed to start server: address already in use: \\.\pipe\nvim-4480-0 WARN 2022-04-30… server_start:154: Failed to start server: address already in use: \\.\pipe\nvim-2168-0 SOLUTION ------------------------------------------------------------------------ 1. Set $NVIM to the parent v:servername, *only* in child processes. - Now the correct way to detect a "parent" Nvim is to check for $NVIM. 2. Do NOT set $NVIM_LISTEN_ADDRESS in child processes. 3. On startup if $NVIM_LISTEN_ADDRESS exists, unset it immediately after server init. 4. Open a channel to parent automatically, expose it as v:parent. Fixes #3118 Fixes #6764 Fixes #9336 Ref #8247 (comment) Ref #8696

justinmk · 2022-05-03T13:23:29Z

Nothing we can do about this. Not a bug. Could be a feature request to Vim.

PROBLEM ------------------------------------------------------------------------ $NVIM_LISTEN_ADDRESS has conflicting purposes as both a parameter ("the current process should listen on this address") and a descriptor ("the current process is a child of this address"). This contradiction means the presence of NVIM_LISTEN_ADDRESS is ambiguous, so child Nvim always tries to listen on its _parent's_ socket. This is the cause of lots of "Failed to start server" spam in our test/CI logs: WARN 2022-04-30… server_start:154: Failed to start server: address already in use: \\.\pipe\nvim-4480-0 WARN 2022-04-30… server_start:154: Failed to start server: address already in use: \\.\pipe\nvim-2168-0 SOLUTION ------------------------------------------------------------------------ 1. Set $NVIM to the parent v:servername, *only* in child processes. - Now the correct way to detect a "parent" Nvim is to check for $NVIM. 2. Do NOT set $NVIM_LISTEN_ADDRESS in child processes. 3. On startup if $NVIM_LISTEN_ADDRESS exists, unset it immediately after server init. 4. Open a channel to parent automatically, expose it as v:parent. Fixes neovim#3118 Fixes neovim#6764 Fixes neovim#9336 Ref neovim#8247 (comment) Ref neovim#8696

PROBLEM ------------------------------------------------------------------------ $NVIM_LISTEN_ADDRESS has conflicting purposes as both a parameter ("the current process should listen on this address") and a descriptor ("the current process is a child of this address"). This contradiction means the presence of NVIM_LISTEN_ADDRESS is ambiguous, so child Nvim always tries to listen on its _parent's_ socket. This is the cause of lots of "Failed to start server" spam in our test/CI logs: WARN 2022-04-30… server_start:154: Failed to start server: address already in use: \\.\pipe\nvim-4480-0 WARN 2022-04-30… server_start:154: Failed to start server: address already in use: \\.\pipe\nvim-2168-0 SOLUTION ------------------------------------------------------------------------ 1. Set $NVIM to the parent v:servername, *only* in child processes. - Now the correct way to detect a "parent" Nvim is to check for $NVIM. 2. Do NOT set $NVIM_LISTEN_ADDRESS in child processes. 3. On startup if $NVIM_LISTEN_ADDRESS exists, unset it immediately after server init. 4. Open a channel to parent automatically, expose it as v:parent. Fixes #3118 Fixes #6764 Fixes #9336 Ref #8247 (comment) Ref #8696 (cherry picked from commit b9d97f5)

…18986) feat(server): introduce $NVIM PROBLEM ------------------------------------------------------------------------ $NVIM_LISTEN_ADDRESS has conflicting purposes as both a parameter ("the current process should listen on this address") and a descriptor ("the current process is a child of this address"). This contradiction means the presence of NVIM_LISTEN_ADDRESS is ambiguous, so child Nvim always tries to listen on its _parent's_ socket. This is the cause of lots of "Failed to start server" spam in our test/CI logs: WARN 2022-04-30… server_start:154: Failed to start server: address already in use: \\.\pipe\nvim-4480-0 WARN 2022-04-30… server_start:154: Failed to start server: address already in use: \\.\pipe\nvim-2168-0 SOLUTION ------------------------------------------------------------------------ 1. Set $NVIM to the parent v:servername, *only* in child processes. - Now the correct way to detect a "parent" Nvim is to check for $NVIM. 2. Do NOT set $NVIM_LISTEN_ADDRESS in child processes. 3. On startup if $NVIM_LISTEN_ADDRESS exists, unset it immediately after server init. 4. Open a channel to parent automatically, expose it as v:parent. Fixes #3118 Fixes #6764 Fixes #9336 Ref #8247 (comment) Ref #8696 (cherry picked from commit b9d97f5) Co-authored-by: Justin M. Keyes <justinkz@gmail.com>

justinmk added the terminal built-in :terminal or :shell label Jul 6, 2018

blueyed mentioned this issue Jul 7, 2018

Focus reporting in terminal windows #8704

Open

justinmk added this to the todo milestone Jan 27, 2019

justinmk added good first issue complexity:low Low-risk, self-contained. Do NOT ask "can I work on this", just read CONTRIBUTING.md labels Jan 27, 2019

mhinz added the Hacktoberfest label Sep 26, 2019

justinmk removed the Hacktoberfest label Nov 12, 2019

justinmk modified the milestones: todo, 0.5 Dec 12, 2019

justinmk mentioned this issue Aug 15, 2020

Unset VIM and VIMRUNTIME when start #12759

Closed

janlazo modified the milestones: 0.5, 0.6 Feb 14, 2021

shinymimiq mentioned this issue Jun 17, 2021

Fix #8696 #14838

Closed

This comment was marked as outdated.

Sign in to view

clason modified the milestones: 0.6, 0.7 Nov 30, 2021

zeertzjq added the environment user system environment (terminal, shell, tmux) label Dec 1, 2021

clason mentioned this issue Dec 15, 2021

Running Vim in Neovim's terminal load Nvim #9960

Closed

clason closed this as completed Dec 15, 2021

zeertzjq reopened this Dec 15, 2021

dundargoc removed the good-first-issue label Jan 27, 2022

justinmk mentioned this issue May 2, 2022

introduce $NVIM, unset $NVIM_LISTEN_ADDRESS #11009

Merged

4 tasks

justinmk closed this as completed May 3, 2022

zeertzjq modified the milestones: 0.9, 0.8 Aug 18, 2022

zeertzjq removed the complexity:low Low-risk, self-contained. Do NOT ask "can I work on this", just read CONTRIBUTING.md label Mar 18, 2023

zeertzjq closed this as not planned Won't fix, can't repro, duplicate, stale Mar 18, 2023

zeertzjq mentioned this issue Mar 18, 2023

When $VIMRUNTIME is set, vim lua runtime gets messed up #22717

Closed

zeertzjq added the closed:wontfix current behavior is by design, and change is not desired label Mar 18, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Running Neovim in Vim's terminal triggers E5009 (uses Vim's VIM/VIMRUNTIME) #8696

Running Neovim in Vim's terminal triggers E5009 (uses Vim's VIM/VIMRUNTIME) #8696

blueyed commented Jul 6, 2018

blueyed commented Jul 6, 2018

justinmk commented Jul 6, 2018

justinmk commented Jul 6, 2018

blueyed commented Jul 6, 2018

janlazo commented Jul 6, 2018

jamessan commented Jul 6, 2018

jamessan commented Jul 6, 2018

aspieln3r commented Apr 10, 2020

drosan-dev commented Aug 15, 2020

drosan-dev commented Aug 15, 2020

shinymimiq commented Jun 17, 2021

jamessan commented Jun 19, 2021

This comment was marked as outdated.

clason commented Dec 15, 2021

zeertzjq commented Dec 15, 2021

clason commented Dec 15, 2021

justinmk commented May 3, 2022

Running Neovim in Vim's terminal triggers E5009 (uses Vim's VIM/VIMRUNTIME) #8696

Running Neovim in Vim's terminal triggers E5009 (uses Vim's VIM/VIMRUNTIME) #8696

Comments

blueyed commented Jul 6, 2018

blueyed commented Jul 6, 2018

justinmk commented Jul 6, 2018

justinmk commented Jul 6, 2018

blueyed commented Jul 6, 2018

janlazo commented Jul 6, 2018

jamessan commented Jul 6, 2018

jamessan commented Jul 6, 2018

aspieln3r commented Apr 10, 2020

drosan-dev commented Aug 15, 2020

drosan-dev commented Aug 15, 2020

shinymimiq commented Jun 17, 2021

jamessan commented Jun 19, 2021

This comment was marked as outdated.

clason commented Dec 15, 2021

zeertzjq commented Dec 15, 2021

clason commented Dec 15, 2021

justinmk commented May 3, 2022