Pourquoi vim retournerait un code de sortie différent de zéro si je quitte immédiatement après l'ouverture?

15

Je rencontre un peu un problème étrange avec vimSnow Leopard: je reçois un code de sortie non nul en exécutant simplement vimpuis en quittant.

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

Cependant, si j'utilise le chemin d'accès complet à vim, je ne vois pas ce comportement

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

Au début, je pensais vimvenir de quelque part plus tôt sur mon chemin, mais:

$ which vim
/usr/bin/vim

Je suis donc perdu. Qu'est-ce qui peut causer cela?

MISE À JOUR: Ce problème s'est résolu comme par magie, ce qui me rend très suspect. Ma meilleure théorie actuelle est que j'ai eu un problème avec mon .vimrcou un plugin que j'ai corrigé accidentellement tout en modifiant ma configuration d'une autre manière. Si je peux retrouver exactement ce que j'ai fait pour le réparer, je mettrai certainement à jour ces informations. Merci pour les réponses.

vim osx Hank Gay
la source
Je l'ai corrigé dans un Makefile en ajoutant -u NONE, ce qui indique à vim de ne charger aucun fichier de configuration. Peut aider dans certaines situations.
Boldewyn

Réponses:

14

Avez-vous filetype offdans votre vimrc? Essayez de le remplacer par:

filetype on
filetype off

J'ai eu ce problème en utilisant Pathogen de Tim Pope sur OS X. Cet article m'a aidé à résoudre le problème. Si vous utilisez Pathogen ...

call pathogen#runtime_append_all_bundles()

... faites ceci à la place:

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
la source
C'est un bon point. J'avais déjà résolu ce problème particulier , mais c'est ce qui m'a amené à soupçonner que j'ai accidentellement corrigé une erreur ailleurs dans mon .vimrc.
Hank Gay
Cela a résolu un problème identique pour moi, sauf avec Vundle plutôt qu'avec Pathogen.
Jonah Braun
Tout comme pour ajouter un autre +1, il s'agit d'un ancien correctif, mais cela a fonctionné pour moi en résolvant ce problème en utilisant Vundle sur un système OSX. Je viens de jeter filetype onau-dessus de l'existant filetype off.
Mikey TK
8

Je peux penser à deux explications possibles.

  1. vimest en fait un alias. Notez que whichne montre pas d'alias, vous devez utiliser à la typeplace (sauf si vous exécutez csh ou tcsh).

  2. Vim va chercher un fichier dans un chemin relatif à son répertoire d'installation, qu'il détermine à partir de la recherche argv[0](le nom de l'exécutable tel que transmis par le shell), et ne parvient pas à trouver ce chemin s'il est appelé via un chemin relatif. Ce serait techniquement possible, mais je ne pense pas que Vim le fasse réellement.

Gilles 'SO- arrête d'être méchant'
la source
7

J'obtiens un code de sortie non nul en exécutant simplement vim puis en quittant.

Cela ne se produit pas ici, avec un système similaire: Snow Leopard et la version stock de Vim.

Essayez cette commande:

$ sudo dtruss vim +q

Cela vous donnera une liste de tous les appels système que Vim effectue pendant son initialisation, puis s'arrête immédiatement. ( dtrussest équivalent à straceLinux, si vous l'avez déjà utilisé.)

Ce que vous recherchez est une ligne proche de la fin qui affiche un code d'erreur, généralement -1. L'examen des arguments de l'appel système devrait vous conduire au problème. Une possibilité très probable est un fichier manquant, qui apparaîtra probablement lors d'un open()appel.

Si Vim se ferme correctement lorsqu'il est exécuté de cette façon, vous avez probablement un problème d'autorisation, que le sudonécessaire pour autoriser l' dtrussexécution se déplace. Dans ce cas, vous pouvez probablement le corriger en réparant les autorisations .

Warren Young
la source
Désolé - je suis sur ma machine de travail maintenant et il n'a pas ce comportement. Je serai sûr de le vérifier une fois que je serai à nouveau sur mon ordinateur personnel.
Hank Gay
Si vous ne pouvez pas le comprendre, ajoutez la dtrusssortie à votre question. (Ou du moins, les 25 dernières lignes environ.) Ce qui vous est incompréhensible peut conduire un autre à la bonne réponse.
Warren Young
@nlucaroni: Heureux de l'entendre. Pour la postérité, cependant, laquelle des deux idées de ma réponse l'a corrigé? Autrement dit, avez-vous rencontré un problème d'autorisation qui a été sudo"résolu", vous indiquant que vous deviez exécuter les autorisations de réparation? Ou est-ce plutôt que cela dtrussvous a montré une erreur de syscall, et si oui, laquelle et pourquoi a-t-elle échoué?
Warren Young
erreurs syscall dans l'ouverture de fichiers qui n'étaient pas là. Mon collègue venait de prendre le .vimrépertoire zippé de quelqu'un d'autre et .vimrc, et les choses avaient des chemins complets et des fichiers manquants à partir de plugins inutilisés.
nlucaroni
2

J'avais rencontré ce problème de codes retour. Je l'ai retracée à une loadviewcommande exécutée silencieusement dans mon vimrc qui fournit des vues persistantes:

" 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

Lors de la saisie d'un tampon sans nom de fichier, le silent! loadviews'exécuterait, masquant l'erreur

E32: aucun nom de fichier

ce qui avait également provoqué la mise à un du code retour.

David Thomas
la source