that function blocks on linux.

[FinnPerry]

The that function works properly on windows but on linux it blocks the parent process despite the documentation claiming otherwise. Then when you close the spawned process, the parent process is also closed. that_in_background has the behavior I want but is deprecated.

I'm using open v3.2.0 which is the latest at this time.

[Byron]

I cannot reproduce the blocking xdg-open on Ubuntu 22. Can you be more specific about the platform you are on?

In any case, it's not the first time this was reported and the only way to deal with it is to assume success and spawn the process without waiting for it. I'd love to have an environment for a reproduction to tackle it though.

[FinnPerry]

I'm using arch linux, gui is swaywm. I've verified that calling open::that runs /usr/bin/xdg-open which is from the xdg-utils pacman package. If I call xdg-open from zsh it does block the shell until the process is closed unless it's opening a tab in an already open browser window (tested with firefox) in which case it returns immediately.

On line 196 of src/lib.rs you're calling .wait() on the spawned process so I assume that's where it's getting stuck waiting for the xdg-open to exit. Since you're not able to reproduce the same result is it possible it's due to differing xdg-open implementations? Does yours block when running in the shell?

[Byron]

When using xdg-open by hand and there is no GUI session available, it opens a reader in the terminal and seems to block. However, if there is a GUI session available it will open whichever program it deems fit without blocking, and that works with cargo run -- <file>. However, when there is no GUI session, cargo run -- <file> fails to run any launcher, probably because it can't connect to the terminal then.

I am working on #66 which will grant access to the underlying commands - you could use that to control how exactly the launchers are used.

Would that work for you?

[Byron]

With the latest release I believe you have multiple options to alleviate the issue.

• use open::that_in_background() which isn't deprecated anymore
• use open::commands()[0].spawn() to not wait for errors. Note that ideally, all commands are tried until one spawns successfully, a capability that isn't exposed in the API, but which is done by open::that() under the hood.

The documentation was also improve to make clear that blocking launchers can happen and how to get past it. Please note that the opener crate seems to use Command::spawn() instead and simply doesn't wait for obtaining the result - usually if the spawning works, opening works as well.

I think a path forward could be that you experiment with launching commands() in such a way that works non-blocking and ideally without squelching errors (too much). Maybe with that experience it will be possible to update open::that() to be better more versatile and suitable, on linux at least.

Thank you.