ibhagwan / fzf-lua

Improved fzf.vim written in lua
GNU Affero General Public License v3.0
2.17k stars 142 forks source link

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

Closed kdheepak closed 3 years ago

kdheepak commented 3 years ago

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.

kdheepak commented 3 years ago

I added more prints. This is the closest in the order of execution I've been able to narrow it down:

M.fzf -> M.raw_fzf -> coroutine.yield() -> contents(function(fzf_cb) .. end) -> function(fzf_cb) ... end -> ERROR

The last line of this function is stdout:read_start(read_callback). After the anonymous function that creates the read_callback and calls stdout:read_start(read_callback) returns, the error occurs. Then it appearsread_callback is called.

After stdout:read_start
E5677: Error writing input to shell-command: EPIPE
E5677: Error writing input to shell-command: EPIPE
Inside read_callback
kdheepak commented 3 years ago

@ibhagwan fwiw I'm getting the same error even when using skim

kdheepak commented 3 years ago

I compiled neovim from source and added print statements inside neovim.

This line is where the error is thrown:

https://github.com/neovim/neovim/blob/03bfdd8b9699a734fb0305e4d4c5e9357f1fc223/src/nvim/os/shell.c#L1196-L1197

This callback is passed into this function over here:

https://github.com/neovim/neovim/blob/03bfdd8b9699a734fb0305e4d4c5e9357f1fc223/src/nvim/os/shell.c#L788

So I printed out argv from the function arguments here:

https://github.com/neovim/neovim/blob/03bfdd8b9699a734fb0305e4d4c5e9357f1fc223/src/nvim/os/shell.c#L717-L723

This is the output of the following code:

diff --git a/src/nvim/os/shell.c b/src/nvim/os/shell.c
index 297424585..6a3b4a3e7 100644
--- a/src/nvim/os/shell.c
+++ b/src/nvim/os/shell.c
@@ -722,6 +722,14 @@ static int do_os_system(char **argv,
                         bool silent,
                         bool forward_output)
 {
+  size_t argc = 0;
+  while (argv[argc] != NUL) {
+    argc++;
+  }
+  for(size_t i=1;i<argc;i++)
+  {
+      msg_schedule_emsgf(_("argv[%zu]: %s"), i, argv[i]);
+  }
   out_data_decide_throttle(0);  // Initialize throttle decider.
   out_data_ring(NULL, 0);       // Initialize output ring-buffer.
   bool has_input = (input != NULL && input[0] != '\0');
@@ -1194,7 +1202,7 @@ static void shell_write_cb(Stream *stream, void *data, int status)
     // Can happen if system() tries to send input to a shell command that was
     // backgrounded (:call system("cat - &", "foo")). #3529 #5241
     msg_schedule_emsgf(_("E5677: Error writing input to shell-command: %s"),
-                       uv_err_name(status));
+                       uv_strerror(status));
   }
   stream_close(stream, NULL, NULL);
 }
argv[1]: -c
argv[2]: git  --git-dir='/Users/USER/gitrepos/dotfiles/.git' --work-tree='/Users/USER/gitrepos/dotfiles' rev-parse --is-inside-work-tree
argv[1]: -c
argv[2]: git  --git-dir='/Users/USER/gitrepos/dotfiles/.git' --work-tree='/Users/USER/gitrepos/dotfiles' diff --name-status --relative HEAD
E5677: Error writing input to shell-command: broken pipe
argv[1]: -c
argv[2]: git  --git-dir='/Users/USER/gitrepos/dotfiles/.git' --work-tree='/Users/USER/gitrepos/dotfiles' ls-files --exclude-standard --others
E5677: Error writing input to shell-command: broken pipe

This system call appears to work fine:

git  --git-dir='/Users/USER/gitrepos/dotfiles/.git' --work-tree='/Users/USER/gitrepos/dotfiles' rev-parse --is-inside-work-tree

But the next two appear to fail. Also, I used uv_strerror(status) and that prints out broken pipe as the error message.

@ibhagwan, any idea what might be going on here?

ibhagwan commented 3 years ago

Not sure yet what's going on, I'll take a deeper look soon but I did notice one thing... you're fzf-lua plugin seems to be outdated, I no longer use the --git-dir and --work-tree, they were replaced with a single arg -C.

kdheepak commented 3 years ago

Omg my fzf-lua is 113 commits behind ?! I've been running PackerUpdate but it didn't get the latest version ?!?

kdheepak commented 3 years ago

I updated to the latest fzf-lua and I'm no longer getting any error messages 😓 I'm SO sorry for wasting all your time on this. I have no idea how this happened, I'm so embarrased.

ibhagwan commented 3 years ago

I updated to the latest fzf-lua and I'm no longer getting any error messages sweat I'm SO sorry for wasting all your time on this. I have no idea how this happened, I'm so embarrased.

Don't worry about it! you did most of the work and it's been quite an astonishing debugging feat on your end all the way to compiling neovim from source... talk about dedication.

I'm just happy it's all working well for you now :-)

kdheepak commented 3 years ago

I’m still so surprised that that happened. I even tried using git reflog in the repo to see if I could figure out what happened but no luck. Baffling.

vijaymarupudi commented 3 years ago

Wow, that must have been so frustrating! Sorry about the @kdheepak, but I'm glad you can use it without bugs though. If you're really curious, maybe you could use git bisect, but I'm content with being happy with current start of affairs :)

kdheepak commented 3 years ago

Using git bisect is a good idea. I suspect the change @ibhagwan mentioned is what changes the behavior. I’ll try it when I get the chance.