Perché vim restituisce un codice di uscita diverso da zero se esco immediatamente dopo l'apertura?

15

Sto riscontrando un po 'di uno strano problema con vimSnow Leopard: ottengo un codice di uscita diverso da zero semplicemente eseguendo vime quindi chiudendo.

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

Tuttavia, se utilizzo il percorso completo per vim, non vedo questo comportamento

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

All'inizio ho pensato che vimvenisse da qualche parte prima nel mio percorso, ma:

$ which vim
/usr/bin/vim

Quindi sono in perdita. Che cosa potrebbe causare questo?

AGGIORNAMENTO: Questo problema si è risolto magicamente, il che mi rende molto sospettoso. La mia migliore teoria attuale è che ho avuto un problema con il mio .vimrco un plugin che ho risolto accidentalmente mentre ottimizzavo la mia configurazione in qualche altro modo. Se riesco a rintracciare esattamente cosa ho fatto per risolverlo, aggiornerò sicuramente con quelle informazioni. Grazie per le risposte

vim osx

— Hank Gay
fonte

L'ho corretto in un Makefile aggiungendo -u NONE, che dice a Vim di non caricare alcun file di configurazione. Potrebbe aiutare in alcune situazioni.

— Boldewyn,

14

Hai filetype offnel tuo vimrc? Prova a sostituirlo con:

filetype on
filetype off

Ho avuto questo problema usando il Pathogen di Tim Pope su OS X. Questo articolo mi ha aiutato a risolvere il problema. Se si utilizza Pathogen ...

call pathogen#runtime_append_all_bundles()

... fallo invece:

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
fonte

Questo è un buon punto. Avevo già risolto questo particolare problema, ma è ciò che mi ha portato a sospettare di aver accidentalmente corretto un errore altrove nel mio .vimrc.

— Hank Gay,

Questo risolto un problema identico per me, tranne con Vundle piuttosto che Pathogen.

— Jonah Braun,

Proprio come aggiungere un altro +1, questa è una vecchia correzione, ma ha funzionato per me risolvendo questo problema usando Vundle su un sistema OSX. Ha appena gettato filetype onsopra l'esistente filetype off.

— Mikey TK,

8

Mi vengono in mente due possibili spiegazioni.

vimè in realtà un alias. Nota che whichnon mostra gli alias, dovresti typeinvece usare (a meno che tu non stia eseguendo csh o tcsh).
Vim cerca un file in un percorso relativo alla sua directory di installazione, che determina guardando argv[0](il nome dell'eseguibile passato dalla shell), e in qualche modo non riesce a trovare quel percorso se viene chiamato attraverso un percorso relativo. Sarebbe tecnicamente possibile, ma non credo che Vim lo faccia davvero.

— Gilles 'SO- smetti di essere malvagio'
fonte

7

Ottengo un codice di uscita diverso da zero semplicemente eseguendo vim e quindi chiudendo.

Questo non succede qui, con un sistema simile: Snow Leopard e la versione stock di Vim.

Prova questo comando:

$ sudo dtruss vim +q

Questo ti fornirà un elenco di tutte le syscalls che Vim fa mentre si inizializza e quindi si spegne immediatamente. ( dtrussequivale a stracesu Linux, se l'hai già usato prima.)

Quello che stai cercando è una riga vicino alla fine che mostra un codice di errore, in genere -1. Osservare gli argomenti della chiamata di sistema dovrebbe portare al problema. Una possibilità ad alta probabilità è un file mancante, che probabilmente verrà visualizzato durante una open()chiamata.

Se Vim esce in modo pulito quando viene eseguito in questo modo, probabilmente hai un problema di autorizzazione, che è sudonecessario dtrussaggirare. In tal caso, probabilmente puoi risolverlo riparando le autorizzazioni .

— Warren Young
fonte

Siamo spiacenti, ora sono sulla mia macchina di lavoro e non ha questo comportamento. Sarò sicuro di verificarlo una volta che sarò di nuovo sulla mia macchina di casa, però.

— Hank Gay,

Se non riesci a capirlo, aggiungi l' dtrussoutput alla tua domanda. (O almeno, le ultime 25 righe o giù di lì.) Ciò che ti è incomprensibile può portare un altro alla risposta giusta.

— Warren Young

@nlucaroni: felice di sentirlo. Per i posteri, quale delle due idee nella mia risposta l'ha risolto? Cioè, hai avuto un problema di autorizzazione che sudo"risolto", facendoti sapere che era necessario eseguire le autorizzazioni di riparazione? O è stato piuttosto che dtrussti ha mostrato un errore syscall, e in caso affermativo, quale e perché non ha funzionato?

— Warren Young,

errori syscall nell'apertura di file che non c'erano. Il mio collega aveva appena preso la .vimdirectory zipp'd di qualcun altro .vimrce le cose avevano percorsi completi e file mancanti da plugin inutilizzati.

— nlucaroni,

2

Ho riscontrato questo problema con i codici di ritorno. L'ho rintracciato in un loadviewcomando di esecuzione silenziosa nel mio vimrc che fornisce visualizzazioni persistenti:

" 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

Quando si immette un buffer senza un nome file, silent! loadviewverrà eseguito nascondendo l'errore

E32: nessun nome file

che aveva anche causato l'impostazione del codice di ritorno su uno.

— David Thomas
fonte