Use $BROWSER variable on Linux for links

[clarfonthey]

This would be nice considering how that variable should take precedence over whatever the default program is.

[Byron]

On linux standard programs respective programs are used and I would hope they do everything by the book.
I wouldn't want to put any kind of special behaviour into this crate directly though. What do you think?

[clarfonthey]

So actually, there are multiple standards, and command-line apps are expected to obey BROWSER which XDG does not obey. See: https://wiki.archlinux.org/index.php/default_applications#Set_default_applications

Also for the record, cargo doc does use the $BROWSER variable.

[Byron]

To me it seems that open would have to try to fix existing programs by bypassing the standard one in case the $BROWSER variable exists and it knows that the program it would want to use disobeys it.
Then it would have to try to detect if it should open an URL that can be handled by the browser (maybe just http/https to play it safe), and launch it directly probably via a shell to make use of the PATH

It doesn't sound easy to do and probably requires some testing to get right - however, if you feel you need it, please feel free to implement it.

Please note that to me this would warrant a major version jump just because the existing behaviour might change considerably for some.

[BartMassey]

The default "browser" on my machine seems to be the Calibre e-book reader through "/bin/ebook-reader". This is not ideal. Honoring the BROWSER variable would be great.

[Byron]

I presume you are trying to open http(s) links? It would be interesting to know as one proposed solution suggests to fix launchers that ignore the BROWSER environment variable by launching the respective browser itself.

However, I don't think I am going to tackle this, as the potential for unwanted side-effects seems too huge.

[BartMassey]

The crate docs need to be clear about whether this thing is intended to open files in the browser, or open files with a registered application for the file type.

If in the browser, then honoring the BROWSER variable on Linux is pretty necessary, as this is the primary way that things including cargo doc do this.

If with a registered application, this should be clearly documented, including some of the standard "unexpected consequences" of this plan given the state of MIME types on all three major platforms but especially on Linux. XDG/Gnome/KDE is a mess here: xdg-open often does not do what is intended, and may not work at all well for folks using a window system not hard-coded in the xdg-open script.

[Byron]

I could imagine to add a new section to the documentation of that() that explains the situation on linux better, also to make clear that $BROWSER may or may not be used depending on the launcher that ends up being called. Your help with this is appreciated.

[Eusebius1920]

Also worth mentioning / considering: Custom-schema uris like some-programm://lorem/ipsum/path are usually handled via xdg and not $BROWSER, still they are URIs.

[BartMassey]

1. "Use this library to open a path or URL using the program configured on the system in a non-blocking fashion." Replace with something like "This library will open a given path or URL in some application, obeying the current user's desktop configuration. It is expected that http: and https: URLs will open in a web browser, although desktop configuration may override this. The choice of application for opening other path types is highly system-dependent."

2. Give some examples of non-URL path opening.

---

UNIX Desktop

The choice of application for opening a given URL or path on a UNIX desktop is highly dependent on the user's GUI framework (if any) and its configuration. open tries a sequence of opener commands to open the specified path. The configuration of these openers is dependent on the window system.

On a console, results will likely be poor. The openers expect to be able to open in a new or existing window, something that consoles lack.

On Windows WSL, wslview is tried first, then xdg-open. In other UNIX environments, xdg-open is tried first. If this fails, a sequence of other openers is tried.

Currently the BROWSER environment variable is ignored even for http: and https: URLs.

It cannot be overemphasized how fragile this all is in UNIX environments. It is common for the various MIME tables to incorrectly specify the application "owning" a given filetype. It is common for openers to behave strangely. Use with caution.

[BartMassey]

(I don't see how the behavior of that_in_background() helps in case an opener blocks? Command::status_without_output() will block in this case, I think, so the path will not be opened successfully and no other openers will be tried.)

[Byron]

Thanks a lot! I have added this PR for feedback before merging, which will conclude this issue, essentially as 'not-planned' as I don't intend to try and fix opening URLSs on any platforms.

[ilyagr]

https://github.com/amodm/webbrowser-rs/blob/main/src/unix.rs is an example of how this can be done. I don't know how well that implementation works, though.

[Byron]

Thanks so much for sharing!

It seems like the webbrowser crate is the one to use when this functionality is desired.

Looking at the API example…

use webbrowser;

if webbrowser::open("http://github.com").is_ok() {
    // ...
}

I don't even think that open should try break into this functionality as this crate solves it beautifully and a mix of open and webbrowser should be able to handle all the tasks.

On that basis, I am closing this issue as a superior solution seems to exist.