`rustup doc` ignores xdg-open environment variables

[xloem]

Problem

I'm trying to read documentation on a headless system, and it is not opening.

Steps

1. observe this works: DISPLAY= BROWSER=links xdg-open https://rustlang.org
2. observe this fails: DISPLAY= BROWSER=links rustup doc

Possible Solution(s)

No response

Notes

No response

Rustup version

1.24.3

Installed toolchains

aarch64-linux-android
x86_64-unknown-linux-gnu

[kinnison]

We use https://github.com/Seeker14491/opener to open URLs - @Seeker14491 is this a known problem, is it something wrong with how we use your crate?

[Seeker14491]

rustup calls opener::open_browser(), which checks if the BROWSER environment variable is set, and if so, it launches the specified program directly (without using xdg-open).

In this case, the issue with using the links browser is that we intentionally spawn the command with a null stdin and stdout, which links does not support. The reason for the null stdin is to avoid the situation where after opening a graphical browser, the terminal is "hijacked" (as in not being able to run other commands) until the browser is closed. And a null stdout stops the terminal from being littered with the debug output that graphical browsers commonly emit.

I'm not sure what a good fix would be. Using a hardcoded list of text-based browsers which shouldn't have null stdin/out feels hacky.

[xloem]

quick thoughts/ideas from the complainant:

• hardcoded list of gui browsers rather than text browsers
• checking if DISPLAY is set
• gui browsers often don't hijack the terminal if they have been already launched
• the user could provide an environment variable or other configuration specifying that they do or don't want their terminal hijacked
• the system could prompt the user if something seems awry
• opener could be informed it is being called in a context where hijacking would be fine, such as this single-purpose command