Calling fzf#run with a list as source fail (n)vim is used from git bash
DanSM-5 opened this issue · 25 comments
Checklist
- I have read through the manual page (
man fzf) - I have searched through the existing issues
- For bug reports, I have checked if the bug is reproducible in the latest version of fzf
Output of fzf --version
0.51.0-devel (c5fb0c4)
OS
- Linux
- macOS
- Windows
- Etc.
Shell
- bash
- zsh
- fish
Problem / Steps to reproduce
I noticed some issues running :Lines or :BLines when using nvim under bash from git. The source of the issueis that when the source in the options passed to fzf#run is a list, the source_command will use the type command to get the content of the temporary file. This works fine if called from powershell or cmd as type will do the expected action but for bash (and zsh if you install it) it will fail as type is a shell built-in.
if has_key(dict, 'source')
let source = remove(dict, 'source')
let type = type(source)
if type == 1
let source_command = source
elseif type == 3
let temps.input = s:fzf_tempname()
call s:writefile(source, temps.input)
+ let source_command = (s:is_win ? 'type ' : 'cat ').fzf#shellescape(temps.input)
else
throw 'Invalid source type'
endif
elseI've manually changed the command from type to cat and that fixes the issue but it is hard to identify when bash/zsh is the current interactive shell. I'd suggest to provide some global variable like g:fzf_cat that if present, it will be used instead of choosing between type and cat.
If the detection route is preferred, checking for the environment variable $SHELL should work as it won't be set neither from cmd nor powershell.
I wonder if this patch fixes your issue:
diff --git a/plugin/fzf.vim b/plugin/fzf.vim
index b73f2aa..02dd60c 100644
--- a/plugin/fzf.vim
+++ b/plugin/fzf.vim
@@ -508,19 +508,19 @@ try
endif
if has_key(dict, 'source')
- let source = remove(dict, 'source')
+ let source = dict.source
let type = type(source)
if type == 1
- let source_command = source
+ let prefix = '('.source.')|'
elseif type == 3
let temps.input = s:fzf_tempname()
call s:writefile(source, temps.input)
- let source_command = (s:is_win ? 'type ' : 'cat ').fzf#shellescape(temps.input)
+ let prefix = (s:is_win ? 'type ' : 'cat ').fzf#shellescape(temps.input).'|'
else
throw 'Invalid source type'
endif
else
- let source_command = ''
+ let prefix = ''
endif
let prefer_tmux = get(g:, 'fzf_prefer_tmux', 0) || has_key(dict, 'tmux')
@@ -544,11 +544,7 @@ try
endif
" Respect --border option given in $FZF_DEFAULT_OPTS and 'options'
let optstr = join([s:border_opt(get(dict, 'window', 0)), s:extract_option($FZF_DEFAULT_OPTS, 'border'), optstr])
- let prev_default_command = $FZF_DEFAULT_COMMAND
- if len(source_command)
- let $FZF_DEFAULT_COMMAND = source_command
- endif
- let command = (use_tmux ? s:fzf_tmux(dict) : fzf_exec).' '.optstr.' > '.temps.result
+ let command = prefix.(use_tmux ? s:fzf_tmux(dict) : fzf_exec).' '.optstr.' > '.temps.result
if use_term
return s:execute_term(dict, command, temps)
@@ -559,14 +555,6 @@ try
call s:callback(dict, lines)
return lines
finally
- if exists('source_command') && len(source_command)
- if len(prev_default_command)
- let $FZF_DEFAULT_COMMAND = prev_default_command
- else
- let $FZF_DEFAULT_COMMAND = ''
- silent! execute 'unlet $FZF_DEFAULT_COMMAND'
- endif
- endif
let [&shell, &shellslash, &shellcmdflag, &shellxquote] = [shell, shellslash, shellcmdflag, shellxquote]
endtry
endfunction
@@ -596,8 +584,8 @@ function! s:fzf_tmux(dict)
endif
endfor
endif
- return printf('LINES=%d COLUMNS=%d %s %s - --',
- \ &lines, &columns, fzf#shellescape(s:fzf_tmux), size)
+ return printf('LINES=%d COLUMNS=%d %s %s %s --',
+ \ &lines, &columns, fzf#shellescape(s:fzf_tmux), size, (has_key(a:dict, 'source') ? '' : '-'))
endfunction
function! s:splittable(dict)
@@ -727,7 +715,8 @@ function! s:execute(dict, command, use_height, temps) abort
let a:temps.shellscript = shellscript
endif
if a:use_height
- call system(printf('tput cup %d > /dev/tty; tput cnorm > /dev/tty; %s < /dev/tty 2> /dev/tty', &lines, command))
+ let stdin = has_key(a:dict, 'source') ? '' : '< /dev/tty'
+ call system(printf('tput cup %d > /dev/tty; tput cnorm > /dev/tty; %s %s 2> /dev/tty', &lines, command, stdin))
else
execute 'silent !'.command
endifIt's basically reverting what I did in 7411da8.
fzf#run forces using cmd.exe via s:use_sh
Lines 447 to 458 in 4bedd33
so type should be available, but instead of directly executing the command, we're setting $FZF_DEFAULT_COMMAND so that fzf launches the process instead. And the behavior depends on $SHELL.
Another option would be to temporarily switch $SHELL as well in s:use_sh. But this is probably not a good idea.
diff --git a/plugin/fzf.vim b/plugin/fzf.vim
index b73f2aa..aa0ac02 100644
--- a/plugin/fzf.vim
+++ b/plugin/fzf.vim
@@ -447,6 +447,7 @@ endfunction
function! s:use_sh()
let [shell, shellslash, shellcmdflag, shellxquote] = [&shell, &shellslash, &shellcmdflag, &shellxquote]
if s:is_win
+ let $SHELL = 'cmd.exe'
set shell=cmd.exe
set noshellslash
let &shellcmdflag = has('nvim') ? '/s /c' : '/c'
@@ -567,7 +568,7 @@ finally
silent! execute 'unlet $FZF_DEFAULT_COMMAND'
endif
endif
- let [&shell, &shellslash, &shellcmdflag, &shellxquote] = [shell, shellslash, shellcmdflag, shellxquote]
+ let [$SHELL, &shell, &shellslash, &shellcmdflag, &shellxquote] = [shell, shell, shellslash, shellcmdflag, shellxquote]
endtry
endfunction
I decided to apply the first patch, as I don't really think temporarily swapping $FZF_DEFAULT_COMMAND is a good idea, and a typical source command will terminate itself when its output stream is broken. Please update and see if it helps.
Yes, it does fixes the issue. Thanks!
Dear @DanSM-5 , would you mind specifying your Windows version? Using latest fzf 0.52.1 and Git Bash, I can run :FZF from Vim in Git Bash in Windows 11, but not under Windows 10. Under Windows 10, only an empty cmd prompt shows up that can be exited to return to Vim. Fzf works fine in Git Bash itself. I am out of ideas why this does not work on Windows 10.
Okay, the solution is given in the open issue #1983
Not sure why the fix is not applied?
I also wonder why Windows 11 does not suffer from this
I have windows 11. I think I've encounter the issue described in #1983 and I called cmd as cmd.exe //c from git bash.
@Konfekt what do you get if you echo $MSYSTEM? I kind of remember that it may be an issue if get MSYS and not MINGW as the value.
Could you try starting git bash like this from powershell and test if :FZF works for you?
& "$env:PROGRAMFILES/Git/usr/bin/env.exe" MSYS=enable_pcon MSYSTEM=MINGW64 enable_pcon=1 /usr/bin/bash -ilThank you for your assistance. The same issue persisted.
What works wonders is either adding the suggested environment variable or rather doubling the initial slashes
let command = 'cmd.exe ///C '.fzf#shellescape('set "TERM=" & start /WAIT sh -c '.shellscript)Curiously, this breaks :FZF under Windows 11. So a case distinction is in order?
Do you have same git version? Recent versions of git change the MSYS runtime which could cause those differences you experience.
Is git bash in your path in both PCs?
What works under both versions, 10 and 11, is MSYS_NO_PATHCONV=1 as proposed in #1983
I tried with the same latest git, vim and fzf version by scoop.
How did you get it working under Windows 10?
I find it rather likely that issue #1983, probably using Windows 10 as it is from April 2020, is still open
Recent versions of git change the MSYS runtime
Would you mind explaining how this affects this issue?
How did you get it working under Windows 10?
I don't have windows 10. I mentioned above I use windows 11.
Would you mind explaining how this affects this issue?
Sure, at some point I started experiencing dandavison/delta#1318. The root cause came from some changes in MSYS which git bash uses. dscho/msys2-runtime@10e99fe
I don't have windows 10. I mentioned above I use windows 11
As it works fine under Windows 11 with the exact same setup, but not under Windows 10,
I find it unlikely that MSYS is the cause, but rather (Conhost ?!) differences between the Windows versions.
I find it unlikely that MSYS is the cause
I asked about the git version to rule out this. Conhost is the terminal but I don't think it influences the environment. You could try the git bash terminal (I think it is MinTTY) or Windows Terminal to see if anything changes.
You could try the git bash terminal (I think it is MinTTY) or Windows Terminal to see if anything changes.
Yes, I tried other terminals, notably the latest Git Bash terminal. Nothing changes. That's why I'd have appreciated your testing on Windows 10 to confirm.
@Konfekt I figured out your issue. I got the clue from #1983 as the addition for MSYS_NO_PATHCONV checks for the following has('win32unix'). It is only true in the version of vim that comes with git bash (and probably with cygwing as per the help description). I found that I have neovim and vim from scoop higher in my path which return false to that feature check but they return true to has('win32').
If I load fzf and fzf.vim in the vim from git bash it does what you describe, it goes directly into cmd.exe.
Could you try downloading neovim (to avoid confusion with vim) and try there? If has('win32unix') is false, it should work fine.
It is only true in the version of vim that comes with git bash (and probably with cygwing as per the help description)
Yes, the fix only applies for Vim in Git Bash which sets has('win32unix').
Since this issue's title contained
vim is used from git bash
I thought it to be about Vim from git bash.
There's no issue for any other Vim executable, say that installed by Scoop;
it worked fine in any other terminal, but not for Git Bash, which I however use by preference.
For some reason, the issue for Vim in Git Bash is gone in Windows 11 on my computer, but yet there in Windows 10, as one expects if bash converts any arguments containing / such as in cmd /c to a path.
Interesting that you can reproduce it for Vim in Git Bash in Windows 11. (I can't.) Are you using the latest versions?
In view of this, replacing /C by ///C or adding MSYS_NO_PATHCONV=1 might fix be considered a universal fix. Could you try it in
Line 714 in 030428b
Since MSYS_NO_PATHCONV=1 also refrains from converting paths passed in s:command, but only /C should not be converted, doubling / in /C is the finer solution. Could you check that it works for you? Seemingly, depending on the environment, slashes had to be quadrupled.
In my case I can see the same issue happening in windows 11 (make sure in your window 11 pc you are calling the same vim). I imagine it happens on the cygwin version of vim specifically (as the description of the feature had('win32unix') implies).
I have other vim excutables due to other issues happening in the provided vim with git bash, thus I ensured to have it lower in my path.
Could you try it in
I'll try that later.
Thank you for your testing. I am testing in a Windows 10 VM, where, as for junegunn, doubling the forward slash works wonders. However, on the Windows 11 machine no slash was needed, whereas the Windows 10 machine demanded three of them. Since this has been merged, it would be good to have some proven record.
When I open git bash's vim executable and I run something like :FZF or :LINES (from fzf.vim), it opens a new window terminal with the fzf. You can choose something and the selection will open back to the initial terminal window.
I believe that's the expected behavior. If so, it should be working fine.