Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Got non-zero code from vifm: 127 #8

Closed
von opened this issue Nov 21, 2016 · 6 comments
Closed

Got non-zero code from vifm: 127 #8

von opened this issue Nov 21, 2016 · 6 comments
Assignees

Comments

@von
Copy link

von commented Nov 21, 2016

EditVifm, which was working for me for consistently, is now failing consistently with "Got non-zero code from vifm: 127"

vim and vifm both latest from homebrew (see below). vifm.vim is latest (f376392). Selection of file with vifm seems to work fine.

Any suggestions to debug?

Thanks.

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Oct 28 2016 19:35:33)

% vifm --version
Version: 0.8.2
Git info: built out of repository
Compiled at: Jul 17 2016 17:29:41

Support of extended keys is on
Parsing of .desktop files is enabled
Without GTK+ library
Without magic library
Without X11 library
Without dynamic loading of X11 library
With file program
With -n option for cp and mv
With remote command execution

@xaizek
Copy link
Member

xaizek commented Nov 22, 2016

I don't remember any recent changes that could affect picking files. What terminal are you using? gnome-terminal is known not to work due to the way it's implemented (#2).

@von
Copy link
Author

von commented Nov 22, 2016

I'm using tmux in iTerm. Running in iTerm outside of tmux doesn't seem to change anything.

Another data point, if I open a new vim process, EditVifm works fine to open the first file, but then fails w/127 when I try to use it to open any file after the first.

@xaizek
Copy link
Member

xaizek commented Nov 22, 2016

Another data point, if I open a new vim process, EditVifm works fine to open the first file, but then fails w/127 when I try to use it to open any file after the first.

That's very strange, the plugin doesn't store any state between invocations, so they shouldn't differ from one another.

There was somewhat similar issue related to v:shell_error in Vim (1196). It's related to patch 8.0.0036, but maybe could affect behaviour before that particular patch (i.e., it just made it more visible). Try removing silent from line 97 to make it look:

execute '!' g:vifm_exec g:vifm_exec_args ldir rdir pickargsstr

Did you update Vim recently? (That could explain why the issue appeared.)

@von
Copy link
Author

von commented Nov 23, 2016

Try removing silent from line 97

Besides now requiring me to press enter after vifm returns, I see no additional output.

Did you update Vim recently? (That could explain why the issue appeared.)

I use homebrew and don't keep careful track. But since the version I have was compiled less than a month ago, it's clearly possible it correlates.

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Oct 28 2016 19:35:33)

@von
Copy link
Author

von commented Nov 23, 2016

I just updated to Vim 8 (2016 Sep 12, compiled Nov 23 2016 17:25:10) and the problem seems to have gone away. Barring some problem, I'll just stick with this version. Feel free to close this issue if you wish.

For the record, I upgraded as described at http://usevim.com/2016/09/12/vim-8-0/:

brew update
brew upgrade --HEAD vim --with-cscope --with-lua --with-override-system-vim

@xaizek
Copy link
Member

xaizek commented Nov 24, 2016

Since there were no changes in the plugin or how files are picked recently and upgrading Vim fixes it, it must be Vim's issue. I also don't know any workaround to make it work in all cases.

Barring some problem, I'll just stick with this version.

If homebrew lets you pick any tag in a repository, you could select slightly older version where v:shell_error isn't broken yet, although I have no issues with Vim 8.

@xaizek xaizek closed this as completed Nov 24, 2016
@xaizek xaizek self-assigned this Nov 24, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants