Calling fzf#run with a list as source fail (n)vim is used from git bash about fzf HOT 25 CLOSED

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.

from fzf.

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
   endif

It's basically reverting what I did in 7411da8.

fzf#run forces using cmd.exe via s:use_sh

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
 

from fzf.

Yes, it does fixes the issue. Thanks!

from fzf.

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.

from fzf.

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

from fzf.

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.

from fzf.

@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 -il

from fzf.

Thank 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)

from fzf.

Curiously, this breaks :FZF under Windows 11. So a case distinction is in order?

from fzf.

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?

from fzf.

What works under both versions, 10 and 11, is MSYS_NO_PATHCONV=1 as proposed in #1983

from fzf.

I tried with the same latest git, vim and fzf version by scoop.
How did you get it working under Windows 10?

from fzf.

I find it rather likely that issue #1983, probably using Windows 10 as it is from April 2020, is still open

from fzf.

Recent versions of git change the MSYS runtime

Would you mind explaining how this affects this issue?

from fzf.

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

from fzf.

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.

from fzf.

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.

from fzf.

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.

from fzf.

@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.

from fzf.

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

from fzf.

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.

from fzf.

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.

from fzf.

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.

from fzf.

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.

from fzf.

Good news, yes, that's also how it's been behaving for me. It's also working fine on Windows 10 and 11 here. Let it remain a mystery why it worked on Windows 11 in the first place.

from fzf.