9

Today, I found my .vimrc didn't take effect. It was ok just hours ago.

When I launched vim with $vim --plugin, :scriptnames echoed nothing: .vimrc file was not sourced. (Note: /etc/vimrc was removed to debug this problem.)

Then I tried to google and found $VIMINIT variable suspicious.

Here is the value of $VIMINIT:

$ echo $VIMINIT
set number

Vim documentation about VIMINIT:

 c. Four places are searched for initializations.  The first that exists
    is used, the others are ignored.  The $MYVIMRC environment variable is
    set to the file that was first found, unless $MYVIMRC was already set.
    -  The environment variable VIMINIT (see also |compatible-default|) (*)
       The value of $VIMINIT is used as an Ex command line.
    -  The user vimrc file(s):
                "$HOME/.vimrc"      (for Unix and OS/2) (*)
                "s:.vimrc"          (for Amiga) (*)
                "home:.vimrc"       (for Amiga) (*)
                "$VIM/.vimrc"       (for OS/2 and Amiga) (*)
                "$HOME/_vimrc"      (for MS-DOS and Win32) (*)
                "$VIM/_vimrc"       (for MS-DOS and Win32) (*)
            Note: For Unix, OS/2 and Amiga, when ".vimrc" does not exist,
            "_vimrc" is also tried, in case an MS-DOS compatible file
            system is used.  For MS-DOS and Win32 ".vimrc" is checked
            after "_vimrc", in case long file names are used.
            Note: For MS-DOS and Win32, "$HOME" is checked first.  If no
            "_vimrc" or ".vimrc" is found there, "$VIM" is tried.
            See |$VIM| for when $VIM is not set.
    -  The environment variable EXINIT.
       The value of $EXINIT is used as an Ex command line.
    -  The user exrc file(s).  Same as for the user vimrc file, but with
       "vimrc" replaced by "exrc".  But only one of ".exrc" and "_exrc" is
       used, depending on the system.  And without the (*)!

I could not understand the vim documentation fully. It seems that $VIMINIT may mess the startup of vim.

Clear $VIMINIT:

$ VIMINIT=
$ echo $VIMINIT

Problem still exist.

  • 2
    "The first that exists is used, the others are ignored." $VIMINIT has precedent over any .vimrc file. And it satisfies the first come first served rule. So yes .vimrc is ignored. – Sukima Dec 18 '15 at 13:28
10

Expanding on @mMontu's answer; Vim hunts for initialization in order of that list till it finds one. Since the $VIMINIT variable take precedent to the .vimrc file, it satisfies the search and any other option after that is ignored.

The reason it still didn't work after:

$ VIMINIT=
$ echo $VIMINIT

Is (1) you're setting a local variable not an environment variable. That needs to be exported:

$ export VIMINIT=

(2) this still won't work because VIMINIT is still defined:

$ printenv | grep VIMINIT
VIMINIT=

What needs to happen is removal from the environment all together:

$ unset VIMINIT
$ printenv | grep VIMINIT || echo "Gone"
Gone

(These commands are Bash specific. Change them to suit your preferred shell if needed.)

  • But this only works for a session, what about unsetting it definitely? or maybe searching where is the variable set, so you can go and delete it? – Feng Yu Dec 19 '15 at 5:53
8

You probably misunderstood the documentation:

 c. Four places are searched for initializations.  The first that exists
    is used, the others are ignored.

Thus if you are using the VIMINIT, the vimrc won't be loaded.

-  The environment variable VIMINIT (see also |compatible-default|) (*)
   The value of $VIMINIT is used as an Ex command line.

You are setting $VIMINIT to an Ex command, set number, which is OK according to the docs. But if prefer a vimrc, you should include set number on that file instead of using $VIMINIT. You mentioned that you set it to empty and your vimrc was still not loaded, but you actually should unset the variable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.