On Sun, 21 Jul 2019 at 21:08:15 -0700, Russ Allbery wrote: > I think it's clear that we're not making forward progress here, and the > lack of a clear specification for the BROWSER environment variable doesn't > seem to be causing a lot of noticable ongoing pain. I'm therefore going > to close this bug as something on which we've just not reached consensus.
As a note for anyone who comes back to this, before the bug gets archived: freedesktop.org has developed a system of URI-scheme handlers since this bug was opened, which as far as I know is used in all the major desktop environments (this is definitely the case for GNOME and the various forks based on older GNOME releases, and I'm fairly sure it's also true for KDE, XFCE, LXDE). In that system, the equivalent of Debian's x-www-browser alternative is to register a MIME type handler for the pseudo-MIME-types "x-scheme-handler/http" and "x-scheme-handler/https". A similar approach works for other URI schemes, for example "x-scheme-handler/mailto". Desktop-oriented libraries should already have a way to launch the default handler for a URI, for example g_app_info_launch_default_for_uri_async() in GLib or bool QDesktopServices::openUrl(const QUrl&) in Qt. This is often a better choice than running a subprocess. Applications that specifically want a command-line/subprocess-based interface can launch a URI in a browser with something like: - xdg-open http://example.com (xdg-utils) - a 1000+-line shell script with many special cases; uses $BROWSER when not in an X11 environment - gio open http://example.com (libglib2.0-bin) - CLI wrapper for g_app_info_launch_default_for_uri_async() - requires GLib, but in practice all mainstream desktop environments are going to have that anyway, e.g. via Firefox or Qt; does not attempt to handle the non-graphical case Regards, smcv
