E5677: Error writing input to shell-command: EPIPE when using `require"fzf-lua".files{cwd = path}`

[kdheepak]

When I call lua require("fzf-lua").files({cwd = "~/gitrepos/dotfiles"}), I get the error:

E5677: Error writing input to shell-command: EPIPE
E5677: Error writing input to shell-command: EPIPE

https://user-images.githubusercontent.com/1813121/131782840-7fe382a7-c8a2-4288-9277-ce55b70678a2.mov

It appears to only happen when I pass in cwd = path. It also never appears when the cwd is the current directory or any subdirectory of the current directory.

[ibhagwan]

Not sure I understand what do you mean when you pass cwd = path, are there certain paths where it works and some where it fails? do the files appear at all and there's an issue with the previewer? I need a bit more info to hone in on where the issue lies exactly.

[kdheepak]

I added a screencast. It seems to fail for me for any path that is not the current directory. The files appear correctly after I hit enter to get rid of the error message.

[ibhagwan]

I added a screencast. It seems to fail for me for any path that is not the current directory. The files appear correctly after I hit enter to get rid of the error message.

Yes I saw the screencast, since it wasn’t full screen I wasn’t sure what was really happening, ok few more questions:

• After you press enter everything seems to work fine or are there other oddities happening? Does the preview work on the first open or only after you move the cursor?
• Does this happen anywhere else with cwd, say the new fixed git_files - does it work with cwd without error?
• Do you have fd installed (I’m trying to figure out if it’s running fd or find)
• Does this also happen if you set default_previewer = “bat” (to see if the issue is preview related)

[ibhagwan]

2 more things:

• Can you provide the exact version of your neovim
• Does this happen on the neovim 0.5 release appimage?

[kdheepak]

I think I narrowed it down. I think it is happening only when I run the following:

    opts.cwd = vim.fn.system("git rev-parse --show-superproject-working-tree --show-toplevel"):gsub("\n", "")
    require("fzf-lua").files(opts)

I have code in my dotfiles that looks like the following

nnoremap("<leader>ff", function(opts)
  opts = opts or {}
  if require("kd/utils").is_git_repo() then
    opts.cwd = vim.fn.system("git rev-parse --show-superproject-working-tree --show-toplevel"):gsub("\n", "")
    require("fzf-lua").files(opts)
  else
    require("fzf-lua").files(opts)
  end
end)

so I wasn't seeing it all the time. Perhaps calling vim.fn.system("git rev-parse --show-superproject-working-tree --show-toplevel") before calling something with fzf-lua is causing this problem? If I remove the opt.cmd = ... I no longer get the error, even if I call lua require("fzf-lua").files({cwd = "~/gitrepos/dotfiles"}).

[kdheepak]

I guess you can close this if you think it is not a fzf-lua issue.

$ nvim --version | head -1 NVIM v0.6.0-dev+206-g284199bc4

[ibhagwan]

I guess you can close this if you think it is not a fzf-lua issue.

$ nvim --version | head -1 NVIM v0.6.0-dev+206-g284199bc4

Great troubleshooting, you’re correct it doesn’t seem related to fzf-lua but you never know, let’s leave this issue open until we get to the bottom of it.

From a quick research this issue seem to be an internal neovim error when running external commands, maybe it’s a bug in your nightly? Can you try with the 0.5 release appimage I linked above?

Also, is this a new issue or was this working before? In the latest nvim-fzf commit https://github.com/vijaymarupudi/nvim-fzf/commit/d811ae553ec83c19941b187a8ac2fee9529cf9e3 the RPC interface changed (to fix nvim-fzf issue #28), although highly unlikely to be the cause I’m just making sure we’re covering all bases.

[ibhagwan]

Btw, what happens if you combine both lines and run this instead:

require'fzf-lua'.files({cwd=vim.fn.system("git rev-parse --show-superproject-working-tree --show-toplevel"):gsub("\n", "")})

Shouldn't make much difference IMO but you never know...

[kdheepak]

I get the error with combining both lines. I included this feature in my dotfiles just this morning. So I don't know if this was working earlier or not. Also good suggestion on trying the v0.5.0 release. I don't appear to be getting the error when I use the stable release of v0.5.0. I'm getting a different error on startup but that might be because I'm using some nightly feature.

[ibhagwan]

I get the error with combining both lines. I included this feature in my dotfiles just this morning. So I don't know if this was working earlier or not. Also good suggestion on trying the v0.5.0 release. I don't appear to be getting the error when I use the stable release of v0.5.0. I'm getting a different error on startup but that might be because I'm using some nightly feature.

If you're using packer you need to run PackerCompile when switching between different versions of neovim.

If it works for you on the 0.5 release it might just be a neovim bug, might be worth narrowing it down even further and opening an issue upstream.

[kdheepak]

I tried with a fresh init.vim file and the latest nightly neovim and I'm not getting the error. Something about my current setup is causing this. Ugh. That's annoying. But I think that is all the more reason to close this issue.

[ibhagwan]

Alright I’ll close it then, btw, if I’m a betting man it’s probably something to do with autocmd’s, perhaps it’s my lucky day too and it’s this one?

https://github.com/kdheepak/dotfiles/blob/d5b51744adc5c11cb970d416f1a37758244ddef3/nvim/lua/kd/config.lua#L119

[kdheepak]

Nice try :) Thanks for looking at my dotfiles to attempt to solve this. I commented that out but no luck. I'm still getting this error. Interestingly, I'm not getting the error if I open vim without loading any buffer. However, if I open vim path/to/file.lua and then run <leader>ff I get this error.

[ibhagwan]

Nice try :) Thanks for looking at my dotfiles to attempt to solve this. I commented that out but no luck. I'm still getting this error. Interestingly, I'm not getting the error if I open vim without loading any buffer. However, if I open vim path/to/file.lua and then run <leader>ff I get this error.

Holy mother of voodoo issues lol

[ibhagwan]

Do you have lazy loaded plugins that only load on BufEnter? If so maybe there is some plug-in that’s causing this that isn’t loaded when you open vim with no buffer.

[kdheepak]

Yeah, almost all my plugins are loaded on BufRead. So that is definitely possible. I'll have to do a bisect on my plugins to debug this.

[kdheepak]

What is EXTREMELY strange is that:

nnoremap("<leader>ff", function(opts)
  opts = opts or {}
  opts.cwd = require("kd/utils").get_git_directory()
  require("fzf-lua").files(opts)
end, {
  label = "Files",
  silent = true,
})

but this doesn't:

nnoremap("<leader>ff", function(opts)
  opts = opts or {}
  require("kd/utils").get_git_directory()
  require("fzf-lua").files(opts)
end, {
  label = "Files",
  silent = true,
})

[ibhagwan]

What is EXTREMELY strange is that:

nnoremap("<leader>ff", function(opts)
  opts = opts or {}
  opts.cwd = require("kd/utils").get_git_directory()
  require("fzf-lua").files(opts)
end, {
  label = "Files",
  silent = true,
})

but this doesn't:

nnoremap("<leader>ff", function(opts)
  opts = opts or {}
  require("kd/utils").get_git_directory()
  require("fzf-lua").files(opts)
end, {
  label = "Files",
  silent = true,
})

When you set cwd there are a few lines of code running that wouldn’t be reached otherwise, I bet that if you do this it won’t work as well:

nnoremap("<leader>ff", function(opts)
  opts = opts or {}
  require("kd/utils").get_git_directory()
  opts.cwd = “~/gitrepos/dotfiles”
  require("fzf-lua").files(opts)
end, {
  label = "Files",
  silent = true,

[ibhagwan]

Another thing to try is adding opts.git_icons = false, that way no git commands will be run, maybe something about running consecutive git commands before and inside fzf lua?

[kdheepak]

Even this seems to cause the issue surprisingly:

nnoremap("<leader>ff", function(opts)
  opts = opts or {}
  opts.cwd = "~/gitrepos/dotfiles/"
  require("fzf-lua").files(opts)
end, {
  label = "Files",
  silent = true,
})

But using opts.git_icons = false throws no error:

nnoremap("<leader>ff", function(opts)
  opts = opts or {}
  opts.cwd = "~/gitrepos/dotfiles/"
  opts.git_icons = false
  require("fzf-lua").files(opts)
end, {
  label = "Files",
  silent = true,
})

I'm going to do a bisect. I suspect another plugin is not interacting with fzf-lua well.

[kdheepak]

Using opts.cwd = "path/to/folder" along with opts.git_icons = false, causes some other issues:

Error executing vim.schedule lua callback: ...local/nvim/share/nvim/runtime/lua/vim/uri.lua:83: Invalid buffer id: 16
Error executing vim.schedule lua callback: ...ck/packer/start/nvim-lspconfig/lua/lspconfig/configs.lua:149: Vim(autocmd):E680: <buffer=16>: invalid buffer number
Error executing vim.schedule lua callback: ...local/nvim/share/nvim/runtime/lua/vim/uri.lua:83: Invalid buffer id: 16
Error executing vim.schedule lua callback: ...ck/packer/start/nvim-lspconfig/lua/lspconfig/configs.lua:149: Vim(autocmd):E680: <buffer=16>: invalid buffer number
Press ENTER or type command to continue

I get this error even if opts.git_icons = true. I get this error ONLY when opts.cwd = "path/to/folder".

[kdheepak]

Omg, something extremely odd is happening.

This is my neovim folder:

$ tree                                                                                                                                                             ─╯
.
├── init.lua
├── lua
│  └── kd
│     ├── config.lua
│     └── plugins.lua
└── plugin
   └── packer_compiled.lua

My init.lua is just two lines:

require("kd/plugins")

require("kd/config")

The plugins.lua file is the following:

$ cat lua/kd/plugins.lua   
───────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: lua/kd/plugins.lua
───────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ M = {}
   2   │
   3   │ local execute = vim.api.nvim_command
   4   │ local fn = vim.fn
   5   │
   6   │ local install_path = fn.stdpath("data") .. "/site/pack/packer/start/packer.nvim"
   7   │
   8   │ if fn.empty(fn.glob(install_path)) > 0 then
   9   │   fn.system({ "git", "clone", "https://github.com/wbthomason/packer.nvim", install_path })
  10   │   execute("packadd packer.nvim")
  11   │ end
  12   │
  13   │ local packer = require("packer")
  14   │ local use = packer.use
  15   │
  16   │ packer.reset()
  17   │ packer.init({ max_jobs = 16 })
  18   │
  19   │ packer.startup({
  20   │   function()
  21   │     -- Packer can manage itself
  22   │
  23   │     use("wbthomason/packer.nvim")
  24   │
  25   │     use({
  26   │       "ibhagwan/fzf-lua",
  27   │       requires = {
  28   │         "vijaymarupudi/nvim-fzf",
  29   │         "kyazdani42/nvim-web-devicons",
  30   │       },
  31   │     })
  32   │
  33   │   end,
  34   │   config = { display = { open_fn = require("packer.util").float } },
  35   │ })
  36   │
  37   │ return M
───────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

And my config file is all commented:

https://github.com/kdheepak/dotfiles/blob/4ac28a0017f586f2188ac1628f6d4796b7e72a0d/nvim/lua/kd/config.lua

And I STILL get the error. However, if I delete the contents of the commented file, the error goes away. SO WEIRD.

https://user-images.githubusercontent.com/1813121/131826898-ee924f45-25d6-486d-9a68-e9e537a532b9.mov

I edited the video a little to make it fit here, but hopefully it is clear what is going on.

[ibhagwan]

Very strange stuff, and just to reiterate, if you go back to 0.5 release everything works fine no matter what right?

And I STILL get the error. However, if I delete the contents of the commented file, the error goes away. SO WEIRD.

TBH, without being able to reproduce it I’m out of ideas, all your troubleshooting just confirms to me this is some voodoo bug in the nightly which seems to be triggered by fzf-lua but I doubt if it’s the cause.

[ibhagwan]

Also, have you tried the latest nightly?

NVIM v0.6.0-dev+210-g6751d6254

[kdheepak]

if you go back to 0.5 release everything works fine no matter what right

I meant to try this but haven’t had the time yet.

Also, have you tried the latest nightly?

I’ll try both versions and open a bug report on neovim’s repo once I have narrowed it down a little more.

[kdheepak]

I'm getting the same error with the latest nightly AND the v0.5.0 stable release.

[kdheepak]

Can you explain how setting cwd propagates through the code? I tried printing out the fzf_cli_args in the raw_fzf function from nvim_fzf and they seem identical. And also, there’s a fzf_cwd option that isn’t being using.

Also, through a print style debugging, I figured out that the error happens during the termopen call in nvim_fzf.

[ibhagwan]

Can you explain how setting cwd propagates through the code? I tried printing out the fzf_cli_args in the raw_fzf function from nvim_fzf and they seem identical. And also, there’s a fzf_cwd option that isn’t being using.

There is no fzf_cwd in my code. as for opts.cwd it's not just one place, there are many places where it's being used, search for opts.cwd and you'll see, it's used in files, grep, git commands and parsing the selected files.

Also, through a print style debugging, I figured out that the error happens during the termopen call in nvim_fzf.

Good progress, maybe @vijaymarupudi has an idea?

[vijaymarupudi]

@kdheepak, can you post the final command being sent to termopen() in nvim_fzf? I'm not sure how termopen() is resulting in an EPIPE.

[kdheepak]

Actually, I don't think it is happening during termopen but it is happening inside nvim_fzf.raw_fzf. This is the command:

fzf < '/var/folders/wk/lcf0vgd90bx0vq1873tn04knk_djr3/T/nvimaQh00z/3'   -
-layout=reverse --bind='ctrl-h:toggle-preview,ctrl-d:preview-half-page-down,ctrl-u:
preview-half-page-up,ctrl-f:page-down,ctrl-b:page-up,ctrl-a:toggle-all,ctrl-l:clear
-query' --prompt='> ' --preview-window=nohidden:right:0 --preview=''\\''nvim'\\'' -
-headless --clean --cmd '\\''luafile /Users/USER/.local/share/nvim/site/pack/pa
cker/start/nvim-fzf/action_helper.lua'\\'' '\\''/var/folders/wk/lcf0vgd90bx0vq1873t
n04knk_djr3/T/nvimaQh00z/2'\\'' 1 {+}' --height=100% --ansi --info=inline --expect=
ctrl-q,ctrl-t,ctrl-s,ctrl-v --multi   > '/var/folders/wk/lcf0vgd90bx0vq1873tn04knk_
djr3/T/nvimaQh00z/4'

I think the error is happening during this coroutine yield: https://github.com/vijaymarupudi/nvim-fzf/blob/d811ae553ec83c19941b187a8ac2fee9529cf9e3/lua/fzf.lua#L182

I'm not sure how the yield works in lua. But a print before the return prints before the error.

[vijaymarupudi]

Ah okay, that means that the error is happening after fzf starts.

What I find odd is the shell escaping in that command, here's how my command looks.

fzf < '/tmp/nvim6OOaUW/86'   --layout=reverse --bind='f2:toggle-preview,f3:toggle-preview-wrap,shift-down:preview-page-
down,shift-up:preview-page-up,ctrl-d:half-page-down,ctrl-u:half-page-up,ctrl-f:page-down,ctrl-b:page-up,ctrl-a:toggle-a
ll,ctrl-l:clear-query' --prompt='> ' --preview-window=nohidden:right:0 --preview=''\''nvim'\'' --headless --clean --cmd
 '\''luafile /chompsky/techno/development/personal/vim/nvim-fzf/action_helper.lua'\'' '\''/tmp/nvim6OOaUW/2'\'' 5 {+}'
--height=100% --ansi --info=inline --expect=ctrl-t,ctrl-s,ctrl-v,ctrl-q --multi   > '/tmp/nvim6OOaUW/87'

I pretty much never have a double backslash. Can you post the command for the variant that works with an error?

[kdheepak]

This is one where there was no error:

"fzf < '/var/folders/wk/lcf0vgd90bx0vq1873tn04knk_djr3/T/nvimqptWMX/3'   -
-layout=reverse --bind='ctrl-h:toggle-preview,ctrl-d:preview-half-page-down,ctrl-u:
preview-half-page-up,ctrl-f:page-down,ctrl-b:page-up,ctrl-a:toggle-all,ctrl-l:clear
-query' --prompt='> ' --preview-window=nohidden:right:0 --preview=''\\''nvim'\\'' -
-headless --clean --cmd '\\''luafile /Users/USER/.local/share/nvim/site/pack/pa
cker/start/nvim-fzf/action_helper.lua'\\'' '\\''/var/folders/wk/lcf0vgd90bx0vq1873t
n04knk_djr3/T/nvimqptWMX/2'\\'' 1 {+}' --height=100% --ansi --info=inline --expect=
ctrl-s,ctrl-v,ctrl-t,ctrl-q --multi   > '/var/folders/wk/lcf0vgd90bx0vq1873tn04knk_
djr3/T/nvimqptWMX/4'"

The previous one was when I was getting the error

[kdheepak]

Here's the screenshot of the diff between the two:

No meaningful difference as far as I could tell.

[kdheepak]

Thanks for looking into this btw, I appreciate it.

[vijaymarupudi]

The double backslashes I think were because of the string representation of lua, you stripped the double quotes off in the first representation, so I mistook it for the actual contents of the string. This is the actual string

fzf < '/var/folders/wk/lcf0vgd90bx0vq1873tn04knk_djr3/T/nvimaQh00z/3'   --layout=reverse --bind='ctrl-h:toggle-preview,ctrl-d:preview-half-page-down,ctrl-u:preview-half-page-up,ctrl-f:page-down,ctrl-b:page-up,ctrl-a:toggle-all,ctrl-l:clear-query' --prompt='> ' --preview-window=nohidden:right:0 --preview=''\''nvim'\'' --headless --clean --cmd '\''luafile /Users/USER/.local/share/nvim/site/pack/packer/start/nvim-fzf/action_helper.lua'\'' '\''/var/folders/wk/lcf0vgd90bx0vq1873tn04knk_djr3/T/nvimaQh00z/2'\'' 1 {+}' --height=100% --ansi --info=inline --expect=ctrl-q,ctrl-t,ctrl-s,ctrl-v --multi   > '/var/folders/wk/lcf0vgd90bx0vq1873tn04knk_djr3/T/nvimaQh00z/4'

Okay, so this is not the issue. I think the next step is to get a stack trace of the error. Can you try using print statements around areas whereuv.write is used in the source code to determine where the error is happening?

[kdheepak]

The errors all seem to be happening before any uv.write. I put print functions before all of these lines and the error occurs before them.

The print in the helper.lua is never called.

[kdheepak]

I tried to make this patch to nvim-fzf:

diff --git a/lua/fzf.lua b/lua/fzf.lua
index f9af516..b3325bd 100644
--- a/lua/fzf.lua
+++ b/lua/fzf.lua
@@ -146,7 +146,7 @@ function FZF.raw_fzf(contents, fzf_cli_args, user_options)

   -- this part runs in the background, when the user has selected, it will
   -- error out, but that doesn't matter so we just break out of the loop.
-  coroutine.wrap(function ()
+  local wrapped = coroutine.wrap(function ()
     if contents then
       if type(contents) == "table" then
         for _, v in ipairs(contents) do
@@ -175,7 +175,8 @@ function FZF.raw_fzf(contents, fzf_cli_args, user_options)
         end, fd)
       end
     end
-  end)()
+  end)
+  wrapped()

   ::wait_for_fzf::

And even require"fzf" is not working:

:lua require"fzf"
E5108: Error executing lua vim.lua:63: ...l/share/nvim/site/pack/packer/start/nvim-fzf/lua/fzf.lua:142: <goto wait_for_fzf> jumps into the scope of local 'wrapped'
Press ENTER or type command to continue

I don't understand why this change is causing issues.

In any case, the last print I'm able to get before the error in a print before this line:

https://github.com/vijaymarupudi/nvim-fzf/blob/d811ae553ec83c19941b187a8ac2fee9529cf9e3/lua/fzf.lua#L182

I was able to confirm that by doing the following:

  print("before coroutine.yield")
  local y = coroutine.yield()
  print("after coroutine.yield")
  return y

With the above change, before coroutine.yield is printed, then the floating window shows up with no fzf inside it, the error message shows up, then fzf loads, and when I hit ESC, after coroutine.yield is printed.

I don't understand where this coroutine.yield() yields to. I'm assuming it yields back to this coroutine in fzf-lua:

https://github.com/ibhagwan/fzf-lua/blob/be5ba9950567a62647fa06bf71af118f7af586ac/lua/fzf-lua/core.lua#L219-L259

This however doesn't have any resume or yield. So I don't fully understand how all this is working.

Based on when I'm seeing the print and when I'm seeing the UI elements in neovim, I'm assuming print always dumps neovim's command output in main thread immediately and the UI updates when the callback is executed on the event loop. So maybe print style debugging is leading me astray here.

[kdheepak]

I even tried putting the print in a coroutine but no luck there. I'm open to suggestions on how to debug this.

Just based on :help E5677, since that is related to the system call, is it possible that this vim.fn.system call is the one that is causing problems?

https://github.com/vijaymarupudi/nvim-fzf/blob/d811ae553ec83c19941b187a8ac2fee9529cf9e3/lua/fzf.lua#L105

Could we use neovim's job control instead of vim.fn.system?

[vijaymarupudi]

Debugging around the coroutine.yield() doesn't tell me much, because pretty much all of nvim-fzf's code runs around that line.

• raw_fzf yields.
• The asynchronous callbacks run and do things
• Finally, everything is done, and the async callbacks resume the yielded function (raw_fzf).
• Then raw_fzf returns.

The system() call cannot be the problem, because we aren't writing to any pipe there.

EPIPE's can only happen once we're writing to a pipe. I'm a bit stumped here.

Currently, the on_exit argument function to termopen does not take any arguments. Can you add the three standard arguments to on_exit and print them? I'm hoping there's some information there to go off of.

[kdheepak]

It is the following: 5 130 "exit"

After coroutine.yield(), do you know what the next line of code is that will be executed?

Also, if you are interested, I can share my screen and you can take a look at what is going on? I'm pretty stumped too.

[vijaymarupudi]

L149 in nvim-fzf/lua/fzf.lua is probably the next. Try all branches of the conditionals. Getting the accurate stack trace is a good road to go down, it'll help us get closer to a situation.

I appreciate the offer, I do really want to solve this, but my schedule is packed, so I can only debug this intermittently. Getting a reproducible example will help, but we clearly don't understand this bug well enough to reproduce it :(

[vijaymarupudi]

It's possible that this approach might also help: https://www.lua.org/pil/8.5.html

[ibhagwan]

Perhaps going on a wild goose chase here but would be interesting to see what happens with sk instead of fzf as I mention in #92.

[kdheepak]

L149 in nvim-fzf/lua/fzf.lua is probably the next.

Perhaps my understand of corountines isn't accurate. Isn't

coroutine.wrap(function() ... end)()

equivalent to

local co = corountine.create(function() ... end)
co.resume()

And I thought co.resume() makes the current coroutine into a "normal" state and calls co. So that block will execute before the current function reaches the final return.

Right?

That's what is happening when I print stuff:

The above screenshot is the content of :messages when I use the following diff:

diff --git a/lua/fzf.lua b/lua/fzf.lua
index f9af516..f3e8b5d 100644
--- a/lua/fzf.lua
+++ b/lua/fzf.lua
@@ -147,13 +147,19 @@ function FZF.raw_fzf(contents, fzf_cli_args, user_options)
   -- this part runs in the background, when the user has selected, it will
   -- error out, but that doesn't matter so we just break out of the loop.
   coroutine.wrap(function ()
+    P("Before if contents then")
     if contents then
+      P('Before if type(contents) == "table"')
       if type(contents) == "table" then
+        P("Before for _, v in ipairs(contents)")
         for _, v in ipairs(contents) do
           local err, bytes = fs_write(fd, tostring(v) .. "\n", -1)
           if err then error(err) end
         end
+        P("After for _, v in ipairs(contents)")
+        P("Before on_done()")
         on_done()
+        P("After on_done()")
       else
         contents(function (usrval, cb)
           if done_state then return end
@@ -179,7 +185,10 @@ function FZF.raw_fzf(contents, fzf_cli_args, user_options)

   ::wait_for_fzf::

-  return coroutine.yield()
+  P("before x = coroutine.yield()")
+  local x = coroutine.yield()
+  P("after x = coroutine.yield()")
+  return x
 end

 function FZF.provided_win_fzf(contents, fzf_cli_args, options)

Although, I'm not confident of trusting print unless some tells me we can trust the order here.

[vijaymarupudi]

You are correct, if the contents are a table, the writing is done synchronously. If contents are a function, then the function at L158 doesn't run until the yield is hit. I'm not sure what the state of the program is when you're running it, so I advised you to try all the locations.

You should definitely also be checking the preview function of fzf.lua too!

[kdheepak]

Oh I see. This is the output:

"lua/kd/config.lua" 305L, 10154C
Before contents(function (usrval, cb)
stack traceback:
^I...l/share/nvim/site/pack/packer/start/nvim-fzf/lua/fzf.lua:159: in function <...l/share/nvim/site/pack/packer/start/nvim-fzf/lua/fzf.lua:149>
E5677: Error writing input to shell-command: EPIPE
E5677: Error writing input to shell-command: EPIPE
Start of function(usrval, cb)
stack traceback:
^I...l/share/nvim/site/pack/packer/start/nvim-fzf/lua/fzf.lua:162: in function 'fzf_cb'
^I...nvim/site/pack/packer/start/nvim-fzf/lua/fzf/helpers.lua:95: in function <...nvim/site/pack/packer/start/nvim-fzf/lua/fzf/helpers.lua:76>
After contents(function (usrval, cb)
Start of function(usrval, cb)
stack traceback:
^I...l/share/nvim/site/pack/packer/start/nvim-fzf/lua/fzf.lua:162: in function 'fzf_cb'
^I...nvim/site/pack/packer/start/nvim-fzf/lua/fzf/helpers.lua:95: in function <...nvim/site/pack/packer/start/nvim-fzf/lua/fzf/helpers.lua:76>
After contents(function (usrval, cb)
Start of function(usrval, cb)
stack traceback:
^I...l/share/nvim/site/pack/packer/start/nvim-fzf/lua/fzf.lua:162: in function 'fzf_cb'
^I...nvim/site/pack/packer/start/nvim-fzf/lua/fzf/helpers.lua:95: in function <...nvim/site/pack/packer/start/nvim-fzf/lua/fzf/helpers.lua:76>
After contents(function (usrval, cb)
End of function(usrval, cb)
End of function(usrval, cb)
Start of function(usrval, cb)
stack traceback:
^I...l/share/nvim/site/pack/packer/start/nvim-fzf/lua/fzf.lua:162: in function 'fzf_cb'
^I...nvim/site/pack/packer/start/nvim-fzf/lua/fzf/helpers.lua:95: in function <...nvim/site/pack/packer/start/nvim-fzf/lua/fzf/helpers.lua:76>
After contents(function (usrval, cb)
End of function(usrval, cb)
End of function(usrval, cb)
"lua/kd/config.lua" 305 lines --16%--

With the following diff:

diff --git a/lua/fzf.lua b/lua/fzf.lua
index f9af516..d57201c 100644
--- a/lua/fzf.lua
+++ b/lua/fzf.lua
@@ -155,7 +155,11 @@ function FZF.raw_fzf(contents, fzf_cli_args, user_options)
         end
         on_done()
       else
+        print("Before contents(function (usrval, cb)")
+        print(debug.traceback())
         contents(function (usrval, cb)
+          print("Start of function(usrval, cb)")
+          print(debug.traceback())
           if done_state then return end
           if usrval == nil then
             on_done()
@@ -170,8 +174,9 @@ function FZF.raw_fzf(contents, fzf_cli_args, user_options)
             end

             if cb then cb(nil) end
-
+          print("End of function(usrval, cb)")
           end)
+          print("After contents(function (usrval, cb)")
         end, fd)
       end
     end

My understanding is that calling the contents function is causing it.

The error occurs between Before contents(function (usrval, cb) and After contents(function (usrval, cb)

This is where the function is passed in in fzf-lua:

    local selected = M.fzf(opts, opts.fzf_fn)

This is where I believe contents function is created in fzf-lua:

  opts.fzf_fn = fzf_helpers.cmd_line_transformer(
    command,
    function(x)
      return core.make_entry_file(opts, x)
    end)

[vijaymarupudi]

In the function passed to cmd_line_transformer, could to place a print statement and check how many times that print statement runs? Or if it runs at all?

[kdheepak]

It seems to get printed for every item in the fzf list:

printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-grayscale-dark.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-grayscale-light-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-grayscale-light.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-greenscreen-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-greenscreen.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-dark-hard-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-dark-hard.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-dark-medium-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-dark-medium.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-dark-pale-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-dark-pale.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-dark-soft-256.itermcolors
Start of function(usrval, cb)
stack traceback:
^I...l/share/nvim/site/pack/packer/start/nvim-fzf/lua/fzf.lua:162: in function 'fzf_cb'
^I...nvim/site/pack/packer/start/nvim-fzf/lua/fzf/helpers.lua:95: in function <...nvim/site/pack/packer/start/nvim-fzf/lua/fzf/helpers.lua:76>
After contents(function (usrval, cb)
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-dark-soft.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-light-hard-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-light-hard.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-light-medium-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-light-medium.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-light-soft-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-light-soft.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-harmonic-dark-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-harmonic-dark.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-harmonic-light-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-harmonic-light.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-hopscotch-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-hopscotch.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-irblack-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-irblack.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-isotope-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-isotope.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-macintosh-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-macintosh.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-marrakesh-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-marrakesh.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-materia-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-materia.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-material-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-material-darker-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-material-darker.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-material-lighter-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-material-lighter.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-material-palenight-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-material-palenight.itermcolors
-- More --printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-grayscale-dark.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-grayscale-light-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-grayscale-light.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-greenscreen-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-greenscreen.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-dark-hard-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-dark-hard.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-dark-medium-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-dark-medium.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-dark-pale-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-dark-pale.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-dark-soft-256.itermcolors
Start of function(usrval, cb)
stack traceback:
^I...l/share/nvim/site/pack/packer/start/nvim-fzf/lua/fzf.lua:162: in function 'fzf_cb'
^I...nvim/site/pack/packer/start/nvim-fzf/lua/fzf/helpers.lua:95: in function <...nvim/site/pack/packer/start/nvim-fzf/lua/fzf/helpers.lua:76>
After contents(function (usrval, cb)
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-dark-soft.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-light-hard-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-light-hard.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-light-medium-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-light-medium.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-light-soft-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-gruvbox-light-soft.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-harmonic-dark-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-harmonic-dark.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-harmonic-light-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-harmonic-light.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-hopscotch-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-hopscotch.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-irblack-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-irblack.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-isotope-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-isotope.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-macintosh-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-macintosh.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-marrakesh-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-marrakesh.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-materia-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-materia.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-material-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-material-darker-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-material-darker.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-material-lighter-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-material-lighter.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-material-palenight-256.itermcolors
printing x:  /Users/USER/gitrepos/dotfiles/base16-iterm2/itermcolors/base16-material-palenight.itermcolors
-- More --

For this diff:

diff --git a/lua/fzf-lua/providers/files.lua b/lua/fzf-lua/providers/files.lua
index ec23db0..530cdff 100644
--- a/lua/fzf-lua/providers/files.lua
+++ b/lua/fzf-lua/providers/files.lua
@@ -42,6 +42,7 @@ M.files = function(opts)

   opts.fzf_fn = fzf_helpers.cmd_line_transformer(command,
     function(x)
+      print("printing x: ", x)
       return core.make_entry_file(opts, x)
     end)

[kdheepak]

The printing all happens after the error btw.

[vijaymarupudi]

Oh, after the error? Now that means this is not the cause.