FZF :Files returns "Command Failed" when using rg in an empty directory in Windows

[vtavares00dev]

• [x ] I have read through https://github.com/junegunn/fzf.vim/blob/master/README.md
• [ x] I have read through https://github.com/junegunn/fzf/blob/master/README-VIM.md
• [x ] I have read through the manual page of fzf (man fzf)
• [x ] I have searched through the existing issues

===

I'm not sure if this is a problem with rg or the way fzf is reacting to rg returning an exit code of 1 (i.e. nothing found) vs > 1 (i.e. an error).

To reproduce:

• install fzf and ripgrep using choco. Works fine from powershell command line

• if I run "rg --files" in an empty directory, the $LastExitCode returns 1, as expected, since rg returned no results. This is not an error, but expected behaviour

• if I run "rg --filez" to intentionally invoke a command failure, I get $LastExitCode of 2, as expected. This is an error.

• Now, in neovim, using stock fzf.vim install with no FZF_DEFAULT_COMMAND environment variable set , it works fine when :Files is invoked in an empty directly. It correctly shows 0/0 results.

• if I set the FZF_DEFAULT_COMMAND='rg --files --no-ignore-vcs --hidden' for fzf to use rg by default, I now get a "[Command failed: rg --files --no-ignore-vcs --hidden]" error and fzf doesn't show anything other than a prompt of the current directory.

• if I move to a directory with files and other directories and run :Files, it works as expected.

Looks like the only difference here is that if rg is run and returns no results, the exit code is 1, which is expected, and fzf bombs out with a Command failed error. This is not specific to :Files, but any rg command that returns an exit code of 1. This is true for :Rg as well. Otherwise it works perfectly fine.

[junegunn]

This is the expected behavior. fzf is just warning you that your custom command reported a non-zero exit status. It doesn't know if 1 can be ignored for ripgrep. If you do not wish to see the message, adjust your command that it never exits with a non-zero code. I don't know how to do it in Windows but you can do it in *nix systems by writing something like some custom command || :.

[vtavares00dev]

Ok, I understand the fzf treats all non-zero exit codes to mean error, but most, if not all grep-like tools, including the actual grep, returns an exit code of 1 to indicate no results returned, not that it was an error. So, according to the convention, fzf should display 0/0, as it does when not using ripgrep in the empty directory.

Not a big deal and I understand that it's the expected behaviour in fzf to print an error message, but I'm just highlighting the convention of exit code 1 in grep and similar search tools to often mean "not found" with errors returning exit code 2 and above.

See:
gnu grep: https://www.gnu.org/software/grep/manual/html_node/Exit-Status.html
ripgrep: BurntSushi/ripgrep#954
ag: ggreer/the_silver_searcher#1070 (comment)
ack: https://beyondgrep.com/documentation/ack-2.12-man.html#shell_and_return_code

Thanks Junegunn.

[junegunn]

according to the convention

I see your point, but it's still a convention not a rule. fzf was designed to work with any kind of program and fzf can't expect them to follow the convention.

> ls foo
ls: foo: No such file or directory
> echo $?
1

[llllvvuu]

Now that :Rg is hardcoded:

\'command!      -bang -nargs=* Rg                               call fzf#vim#grep("rg --column --line-number --no-heading --color=always --smart-case -- ".shellescape(<q-args>), 1, fzf#vim#with_preview(), <bang>0)',

It should be possible to change the implementation of :Rg to handle the exit code of 1 vs 2.