Problem

Sure, the title sounds like the setup to a bad joke. But it's an issue I actually did encounter for real.

If you start nvim while inside a directory that has been deleted (for example by a /tmp-cleaning daemon), then it seems $MYVIMRC changes its logic for resolving symlinks. If init.lua itself is a symlink it still works fine, but if ~/.config/nvim is, then that is not resolved into its real path. This can have adverse effects on configs that look for files relative to $MYVIMRC.

I only talk about init.lua here, but init.vim seems to have the same issue.

Steps to reproduce

(Does not work with -u, needs to be using the default vimrc resolution.)

❯ mv ~/.config/nvim ~/nvim-config # move existing config out of the way
❯ mkdir ~/.config/nvim-real
❯ ln -s nvim-real ~/.config/nvim
❯ echo 'print(vim.env.MYVIMRC)' > ~/.config/nvim-real/init.lua
❯ mkdir /tmp/dir
❯ cd /tmp/dir
❯ nvim
# prints `~/.config/nvim-real/init.lua` at startup
❯ rmdir ../dir
❯ nvim
# prints `~/.config/nvim/init.lua`

Expected behavior

I'd understand if things behave a bit strangely when executing in a directory that does not exist, but I'd expect vimrc resolution to be unaffected. Considering the behavior when init.vim itself is a symlink, and vim's behavior, the expected behavior is probably to show the file's real path in both cases.

Neovim version (nvim -v)

NVIM v0.9.5

Vim (not Nvim) behaves the same?

No, it prints ~/.config/vim-real/vimrc in both cases. (Vim 9.1, compiled May 11 2024 19:59:14)

Operating system/version

Arch Linux

Terminal name/version

MATE Terminal 1.28.1

$TERM environment variable

xterm-256color

Installation

pacman (system package manager)