¿Por qué vim devolvería un código de salida distinto de cero si salgo inmediatamente después de abrir?

15

Me encuentro con un problema un poco extraño con vimSnow Leopard: obtengo un código de salida distinto de cero simplemente ejecutando vimy luego cerrando.

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

Sin embargo, si uso la ruta completa a vim, no veo este comportamiento

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

Al principio pensé que vimvenía de algún lugar anterior en mi camino, pero:

$ which vim
/usr/bin/vim

Entonces estoy perdido. ¿Qué podría estar causando esto?

ACTUALIZACIÓN: Este problema se ha resuelto mágicamente, lo que me hace sospechar mucho. Mi mejor teoría actual es que tuve un problema con mi .vimrco un complemento que arreglé accidentalmente mientras modificaba mi configuración de alguna otra manera. Si puedo rastrear exactamente lo que hice para solucionarlo, definitivamente actualizaré con esa información. Gracias por las respuestas

vim osx

— Hank Gay
fuente

Lo arreglé en un Makefile agregando -u NONE, que le dice a vim que no cargue ningún archivo de configuración. Podría ayudar en algunas situaciones.

— Boldewyn

14

¿Tienes filetype offen tu vimrc? Intenta reemplazarlo con:

filetype on
filetype off

Tuve este problema usando el Patógeno de Tim Pope en OS X. Este artículo me ayudó a resolver el problema. Si está utilizando patógenos ...

call pathogen#runtime_append_all_bundles()

... haz esto en su lugar:

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
fuente

Este es un buen punto. Ya había solucionado este problema en particular , pero es lo que me llevó a sospechar que accidentalmente solucioné un error en otro lugar de mi .vimrc.

— Hank Gay

Esto solucionó un problema idéntico para mí, excepto con Vundle en lugar de Pathogen.

— Jonah Braun

Al igual que agregar otro +1, esta es una solución antigua, pero me funcionó para solucionar este problema usando Vundle en un sistema OSX. Acabo de tirar por filetype onencima de lo existente filetype off.

— Mikey TK

8

Se me ocurren dos posibles explicaciones.

vimEn realidad es un alias. Tenga en cuenta que whichno muestra alias, debe usar typeen su lugar (a menos que esté ejecutando csh o tcsh).
Vim va a buscar algún archivo en una ruta relativa a su directorio de instalación, que determina al mirar argv[0](el nombre del ejecutable como se pasa desde el shell), y de alguna manera no puede encontrar esa ruta si se llama a través de una ruta relativa. Eso sería técnicamente posible, pero no creo que Vim realmente lo haga.

— Gilles 'SO- deja de ser malvado'
fuente

7

Obtengo un código de salida distinto de cero simplemente ejecutando vim y luego saliendo.

Eso no sucede aquí, con un sistema similar: Snow Leopard y la versión estándar de Vim.

Prueba este comando:

$ sudo dtruss vim +q

Eso le dará una lista de todas las llamadas de sistema que hace Vim mientras se inicializa y luego se apaga inmediatamente. ( dtrusses equivalente a straceen Linux, si lo ha usado antes).

Lo que está buscando es una línea cerca del final que muestre un código de error, generalmente -1. Mirar los argumentos de la llamada al sistema debería llevarlo al problema. Una posibilidad de alta probabilidad es la falta de un archivo, que probablemente aparecerá en una open()llamada.

Si Vim sale limpiamente cuando se ejecuta de esta manera, probablemente tenga un problema de permiso, que es sudonecesario para permitir dtrussque se ejecute. En ese caso, probablemente pueda solucionarlo reparando los permisos .

— Warren Young
fuente

Lo siento, ahora estoy en mi máquina de trabajo y no tiene este comportamiento. Sin embargo, me aseguraré de revisarlo una vez que esté en mi máquina doméstica nuevamente.

— Hank Gay

Si no puede resolverlo, agregue el dtrussresultado a su pregunta. (O al menos, las últimas 25 líneas más o menos.) Lo que es incomprensible para usted puede llevar a otro a la respuesta correcta.

— Warren Young

@nlucaroni: Me alegra escucharlo. Sin embargo, para la posteridad, ¿ cuál de las dos ideas en mi respuesta lo arregló? Es decir, ¿tuvo un problema de permisos que se sudo"solucionó" y le hizo saber que necesitaba ejecutar los permisos de reparación? ¿O fue más bien lo que le dtrussmostró un error de syscall, y si es así, cuál y por qué estaba fallando?

— Warren Young

errores de syscall al abrir archivos que no estaban allí. Mi compañero de trabajo acababa de tomar el .vimdirectorio zipp'd de alguien más .vimrc, y las cosas tenían rutas completas y archivos faltantes de complementos no utilizados.

— nlucaroni

2

Había golpeado este problema de códigos de retorno. Lo loadviewrastreé hasta un comando de ejecución silenciosa en mi vimrc que proporciona vistas persistentes:

" 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

Al ingresar un búfer sin un nombre de archivo, silent! loadviewse ejecutará, ocultando el error

E32: sin nombre de archivo

lo que también provocó que el código de retorno se estableciera en uno.

— David Thomas
fuente