Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question

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

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

share|improve this answer
    
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 0:35

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.

share|improve this answer

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.

share|improve this answer
    
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 '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 7 '11 at 22:12
    
Thank you. This worked great! –  nlucaroni Feb 12 '13 at 20:25
    
@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

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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