I'm running into a bit of a strange problem w/ vim on Snow Leopard: I get a non-zero exit code from simply running vim and then quitting.

$ vim
# exit immediately using :q
$ echo $?

However, if I use the full path to vim, I don't see this behavior

$ /usr/bin/vim
# exit immediately using :q
$ echo $?

At first I thought vim was coming from somewhere earlier in my path, but:

$ which vim

So I'm at a loss. What could be causing this?

UPDATE: This problem has magically resolved itself, which makes me highly suspicious. My current best theory is that I had a problem with my .vimrc or a plugin that I fixed accidentally while tweaking my setup in some other way. If I can track down exactly what I did to fix it, I will definitely update with that info. Thanks for the answers.

  • I fixed it in a Makefile by adding -u NONE, which tells vim to load no config file at all. Might help in some situations.
    – Boldewyn
    Nov 16, 2016 at 14:56

4 Answers 4


Do you have filetype off in your vimrc? Try replacing it with:

filetype on
filetype off

I had this problem using Tim Pope's Pathogen on OS X. This article helped me solve the issue. If you are using Pathogen...

call pathogen#runtime_append_all_bundles()

...do this instead:

filetype on
filetype off
call pathogen#runtime_append_all_bundles()
call pathogen#helptags()
filetype plugin indent on


  • This is a good point. I had already fixed this particular issue, but it is what led me to suspect that I accidentally fixed an error somewhere else in my .vimrc.
    – Hank Gay
    Jul 13, 2011 at 15:26
  • This fixed an identical issue for me except with Vundle rather than Pathogen. Feb 13, 2013 at 0:35
  • Just like to add another +1, this is an old fix, but it just worked for me fixing this problem using Vundle on an OSX system. Just threw filetype on above the existing filetype off.
    – Mikey T.K.
    Sep 14, 2015 at 15:50

I can think of two possible explanations.

  1. vim is actually an alias. Note that which doesn't show aliases, you should use type instead (unless you're running csh or tcsh).

  2. Vim goes to look for some file in a path relative to its installation directory, which it determines from looking at argv[0] (the name of the executable as passed from the shell), and somehow fails to find that path if it's called through a relative path. That would be technically possible, but I don't think Vim actually does that.


I get a non-zero exit code from simply running vim and then quitting.

That doesn't happen here, with a similar system: Snow Leopard, and the stock version of Vim.

Try this command:

$ sudo dtruss vim +q

That will get you a list of all the syscalls Vim makes while it initializes and then immediately shuts down. (dtruss is equivalent to strace on Linux, if you've used that before.)

What you're looking for is a line close to the end that shows an error code, typically -1. Looking at the arguments to the system call should lead you to the problem. One high likelihood possibility is a missing file, which will probably show up on an open() call.

If Vim exits cleanly when run this way, you probably have a permission problem, which the sudo needed to allow dtruss to run is getting around. In that case, you can probably fix it by repairing permissions.

  • Sorry - I'm on my work machine now and it doesn't have this behavior. I'll be sure to check it out once I'm on my home machine again, though.
    – Hank Gay
    Jun 6, 2011 at 20:10
  • If you can't figure it out, append the dtruss output to your question. (Or at least, the last 25 lines or so.) What is incomprehensible to you may lead another to the right answer. Jun 7, 2011 at 22:12
  • @nlucaroni: Glad to hear it. For posterity, though, which of the two ideas in my answer fixed it? That is, did you have a permission problem that sudo "fixed", letting you know you needed to run Repair Permissions? Or was it rather that dtruss showed you a syscall error, and if so, which one and why was it failing? Feb 13, 2013 at 12:57
  • syscall errors in opening files that weren't there. My co-worker had just taken someone elses zipp'd .vim directory and .vimrc, and things had full paths and missing files from unused plugins.
    – nlucaroni
    Feb 13, 2013 at 20:02

I had hit this return codes problem. I traced it back to a silently executing loadview command in my vimrc which provides persistent views:

" Persistent views
if has("mksession")
    set viewdir=$HOME/.vimviews
    if has("unix")
        silent execute '!mkdir -p $HOME/.vimviews'
    au BufWinLeave * silent! mkview "make vim save view (state) (folds, cursor, etc)
    au BufWinEnter * silent! loadview "make vim load view (state) (folds, cursor, etc)

When entering a buffer without a filename, the silent! loadview would execute, hiding the error

E32: No file name

which had also caused the return code to be set to one.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .