`opener::open` does not fail at all, even when e.g. file is missing on Linux

[tibordp]

• Fedora 38 + Gnome (Wayland)

Repro:

> xdg-open foo.sav
gio: file:///home/tibordp/foo.sav: Error when getting information for file “/home/tibordp/foo.sav”: No such file or directory
> echo $?
4
> cat repro.rs
#!/usr/bin/env rust-script
//! ```cargo
//! [dependencies]
//! opener = "0.6.1"
//! ```
fn main() {
    const FILE: &str = "foo.sav";
    opener::open(FILE).unwrap();
    println!("{} opened successfully!", FILE);
}
> ./repro.rs 
foo.sav opened successfully!
> echo $?
0

[Seeker14491]

When the system xdg-open fails, as in this case, we fall back to our internal xdg-open script:

https://github.com/Seeker14491/opener/blob/ff6e2599f1360332dac2b87877f9e1694ad654c3/opener/src/linux_and_more.rs#L52-L58

It seems the internal xdg-open erroneously succeeds in this case, so no error is reported. To fix this, maybe we shouldn't be using the fallback in the case where the system xdg-open exists.

[tibordp]

Tried with the bundled xdg-open and it fails as expected

tibordp@mnemosyne:~ $ ./bundled-xdg-open.sh foo.sav
gio: file:///home/tibordp/foo.sav: Error when getting information for file “/home/tibordp/foo.sav”: No such file or directory
tibordp@mnemosyne:~ $ echo $?
4

The way I'm seeing is the problem is that the library just checks if the spawning fails, but does not actually check the exit code of the spawned process.

https://github.com/Seeker14491/opener/blob/master/opener/src/linux_and_more.rs#L69-L98

[Seeker14491]

Ah, you're right, though that is intentional. The issue is that we don't want to block on the open() call, so we don't wait to check the exit code.

[tibordp]

Interesting - is there a reason the crate waits on Mac then? At least on my system, xdg-open exits once the file has been opened and does not wait for the process to terminate.

[Seeker14491]

Yes, on Mac the system-provided open command is used, which doesn't block (unless you pass in the -W flag which waits for the program to exit). On Linux, we can't say in general whether xdg-open will or will not block. In the past, this crate actually did wait for xdg-open's status code so we could detect failure, but we encountered the issue of the command blocking in some environments, so it was changed.