When I run rga-fzf I get error Error: No such file or directory (os error 2)

[TuralAsgar]

Describe the bug
When I run rga-fzf it starts fzf's interactive searching and displays file content with their names.
But when I press Enter to open the file it doesn't open.
Then I use ctrc+c to halt the process.
And I see that the error Error: No such file or directory (os error 2) happened in the console.

To Reproduce

Attach example file:

Run command:
rga-fzf "break down"

Output
Error: No such file or directory (os error 2)

Screenshots

Operating System and Version
macOS 15.0 (24A335)

Output of rga --version
ripgrep-all 0.10.6

[tandetat]

I’m having the same issue in a Macbook Pro M3 Pro running macOS 15.0.1 (24A348) and I think I found the source of the bug.

Lines 14-32 of rga-fzf-open.rs use evince to open pdfs and xdg-open to open other filetypes:

  if fname.ends_with(".pdf") {
        use std::io::ErrorKind::*;
        let worked = Command::new("evince")
            .arg("--find")
            .arg(&query)
            .arg(&fname)
            .spawn()
            .map_or_else(
                |err| match err.kind() {
                    NotFound => Ok(false),
                    _ => Err(err),
                },
                |_| Ok(true),
            )?;
        if worked {
            return Ok(());
        }
    }
    Command::new("xdg-open").arg(fname).spawn()?;

xdg-open is not native to macOs and macOs has its own analogous command open (although you can install xdg-open if you really want to see here for more info. On the other hand, I was able to install evince with brew install evince, and it correctly opened a pdf file but it still threw the error message Error: fzf output not two line.

I believe this part of the code has a few issues. First, it assumes the user has evince installed and xdg-open available as a command and the error message when the user doesn’t fails to clearly indicate the problem. Second, xdg-open should be used when the command is being run on Linux, while ‘open’ should be used for macOs.

One way to fix this is to have something like this

use std::env;

let (cmd, pdf_cmd) = match env::consts::OS {
      “macos" => (“open"  "open -a Preview.app"), //! use native Preview for macOs
      "linux" => ("xdg-open", "evince"), //! use evince for linux
}
  if fname.ends_with(".pdf") {
        use std::io::ErrorKind::*;
        let worked = Command::new(pdf_cmd)
            .arg("--find")
            .arg(&query)
            .arg(&fname)
            .spawn()
            .map_or_else(
                |err| match err.kind() {
                    NotFound => Ok(false),
                    _ => Err(err),
                },
                |_| Ok(true),
            )?;
        if worked {
            return Ok(());
        }
    }
  
    Command::new(cmd).arg(fname).spawn()?;

[chriad]

I had the same problem. As a workaround I created a executable file rga-fzf-open with the following content in my PATH:

#!/usr/bin/env bash
xdg-open $(readlink -f "${@}")

In my case this worked to open a pdf file in my default viewer. As mentioned above use xdg-open or open depending on your OS.

[lafrenierejm]

This should have been fixed for macOS by #260 and would be fixed for Windows by #265.

[KKKZOZ]

This should have been fixed for macOS by #260 and would be fixed for Windows by #265.

When will the next version containing these fixes be released?

If I compile from source, can I get the fixes now?

[lafrenierejm]

This should have been fixed for macOS by #260 and would be fixed for Windows by #265.

When will the next version containing these fixes be released?

That would be a question for @phiresky.

If I compile from source, can I get the fixes now?

#260 has been merged into master, so building from source would get you that fix immediately. #265 has not been merged as of this writing, so to get the Windows fix proposed in it you would need to build from the PR's source branch (which in this case is lafrenierejm:windows-fzf-open).

[KKKZOZ]

@lafrenierejm
Thanks! 🙏

[lafrenierejm]

#265 has not been merged as of this writing, so to get the Windows fix proposed in it you would need to build from the PR's source branch (which in this case is lafrenierejm:windows-fzf-open).

@KKKZOZ #265 was just merged, so you can now just build from master; no need to fetch the branch from my fork.

[KKKZOZ]

#265 has not been merged as of this writing, so to get the Windows fix proposed in it you would need to build from the PR's source branch (which in this case is lafrenierejm:windows-fzf-open).

@KKKZOZ #265 was just merged, so you can now just build from master; no need to fetch the branch from my fork.

Thanks for the notification! 😁

[lafrenierejm]

@phiresky I believe this can be safely marked resolved following #260 and #265.