16

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 $?
1

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

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

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

$ which vim
/usr/bin/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.

Hank Gay
  • 3,549
  • 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 '16 at 14:56

4 Answers4

14

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

http://andrewho.co.uk/weblog/vim-pathogen-with-mutt-and-git

Brandon Bloom
  • 241
  • 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 '11 at 15:26
  • This fixed an identical issue for me except with Vundle rather than Pathogen. – Jonah Braun Feb 13 '13 at 00: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 '15 at 15:50
8

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.

Community
  • 1
Gilles 'SO- stop being evil'
  • 829,060
7

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.

Warren Young
  • 72,032
  • 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 06 '11 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. – Warren Young Jun 07 '11 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? – Warren Young Feb 13 '13 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 '13 at 20:02
2

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'
    endif
    au BufWinLeave * silent! mkview "make vim save view (state) (folds, cursor, etc)
    au BufWinEnter * silent! loadview "make vim load view (state) (folds, cursor, etc)
endif

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.

David Thomas
  • 121
  • 2