Dlaczego vim miałby zwracać niezerowy kod wyjścia, jeśli wychodzę natychmiast po otwarciu?

15

Mam trochę dziwnego problemu z systemem vimSnow Leopard: otrzymuję niezerowy kod wyjścia z samego uruchomienia, vima następnie zamknięcia.

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

Jeśli jednak użyję pełnej ścieżki do vim, nie widzę tego zachowania

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

Na początku myślałem, że vimprzychodzi skądś na mojej drodze, ale:

$ which vim
/usr/bin/vim

Więc jestem zagubiony. Co może być tego przyczyną?

AKTUALIZACJA: Ten problem sam się magicznie rozwiązał, przez co jestem bardzo podejrzliwy. Moja najlepsza teoria jest taka, że miałem problem z moją .vimrcwtyczką, którą naprawiłem przypadkowo podczas dostrajania konfiguracji w inny sposób. Jeśli uda mi się wyśledzić dokładnie, co zrobiłem, aby to naprawić, na pewno zaktualizuję te informacje. Dziękuję za odpowiedzi.

vim osx

— Hank Gay
źródło

Naprawiłem to w pliku Makefile, dodając -u NONE, co mówi vimowi, aby w ogóle nie ładował pliku konfiguracyjnego. Może pomóc w niektórych sytuacjach.

— Boldewyn

14

Czy masz filetype offw swoim vimrc? Spróbuj zastąpić go:

filetype on
filetype off

Miałem ten problem przy użyciu Patogena Tima Pope'a w systemie OS X. Ten artykuł pomógł mi rozwiązać problem. Jeśli używasz Pathogen ...

call pathogen#runtime_append_all_bundles()

... zrób to zamiast tego:

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
źródło

To dobra uwaga. Naprawiłem już ten konkretny problem, ale to mnie skłoniło do podejrzeń, że przypadkowo naprawiłem błąd w innym miejscu .vimrc.

— Hank Gay

To naprawiło dla mnie identyczny problem, z wyjątkiem Vundle zamiast Pathogena.

— Jonah Braun

Podobnie jak dodanie kolejnego +1, jest to stara poprawka, ale po prostu działało dla mnie naprawienie tego problemu za pomocą Vundle na systemie OSX. Właśnie rzuciłem filetype onponad istniejące filetype off.

— Mikey TK

8

Mogę wymyślić dwa możliwe wyjaśnienia.

vimjest właściwie pseudonimem. Zauważ, że whichnie pokazuje aliasów, powinieneś użyć typezamiast tego (chyba że używasz csh lub tcsh).
Vim szuka jakiegoś pliku w ścieżce względem katalogu instalacyjnego, który określa na podstawie patrzenia argv[0](nazwa pliku wykonywalnego przekazanego z powłoki) i jakoś nie znajduje tej ścieżki, jeśli jest wywoływany przez ścieżkę względną. To byłoby technicznie możliwe, ale nie sądzę, żeby Vim tak zrobił.

— Gilles „SO- przestań być zły”
źródło

7

Otrzymuję niezerowy kod wyjścia po prostu uruchamiając vima, a następnie wychodząc.

Tak się nie dzieje w przypadku podobnego systemu: Snow Leopard i podstawowej wersji Vima.

Wypróbuj to polecenie:

$ sudo dtruss vim +q

Otrzymasz listę wszystkich wywołań systemowych Vima podczas inicjalizacji, a następnie natychmiastowego wyłączania. ( dtrussjest równoważne z straceLinuksem, jeśli używałeś go wcześniej).

To, czego szukasz, to linia blisko końca, która pokazuje kod błędu, zwykle -1. Analiza argumentów wywołania systemowego powinna doprowadzić do problemu. Jedną z możliwości wysokiego prawdopodobieństwa jest brakujący plik, który prawdopodobnie pojawi się podczas open()połączenia.

Jeśli Vim zakończy się bezproblemowo, gdy zostanie uruchomiony w ten sposób, prawdopodobnie masz problem z uprawnieniami, którym jest sudopotrzeba dtrussobejścia. W takim przypadku prawdopodobnie możesz to naprawić, naprawiając uprawnienia .

— Warren Young
źródło

Przepraszam - jestem teraz na mojej maszynie roboczej i nie ma tego zachowania. Jednak na pewno to sprawdzę, kiedy znów będę na domowej maszynie.

— Hank Gay

Jeśli nie możesz tego rozgryźć, dołącz dtrusswynik do pytania. (A przynajmniej ostatnie 25 wierszy.) To, co jest dla ciebie niezrozumiałe, może doprowadzić inną do właściwej odpowiedzi.

— Warren Young,

@nlucaroni: Cieszę się, że to słyszę. Ale dla potomności, który z dwóch pomysłów w mojej odpowiedzi to naprawił? To znaczy, czy masz problem z sudo„ pozwoleniem ”, który „naprawił”, informując, że musisz uruchomić uprawnienia do naprawy? A może raczej dtrusspokazywał błąd systemowy, a jeśli tak, to który i dlaczego się nie udaje?

— Warren Young,

błędy syscall podczas otwierania plików, których nie było. Mój współpracownik właśnie zabrał komuś spakowany .vimkatalog .vimrci rzeczy miały pełne ścieżki i brakujące pliki z nieużywanych wtyczek.

— nlucaroni

2

Wystąpił problem z kodami powrotu. Prześledziłem go z powrotem do loadviewkomendy vimrc, która cicho wykonuje polecenie, która zapewnia trwałe widoki:

" 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

Po wprowadzeniu bufora bez nazwy pliku silent! loadviewwykona się, ukrywając błąd

E32: Brak nazwy pliku

co również spowodowało, że kod powrotu został ustawiony na jeden.

— David Thomas
źródło