`rustup doc` appears to do nothing

[Diggsey]

I do see behavior on a headless linux machine where rustup doc appears to do nothing.

https://github.com/rust-lang-nursery/rustup.rs/pull/1046#issuecomment-299998690

[nodakai]

$ docker run -it --name rustup-doc --security-opt seccomp:unconfined debian:jessie
# apt-get update
# apt-get -y install curl less strace
# curl https://sh.rustup.rs -sSf | sh
# PATH=$PATH:$HOME/.cargo/bin
# strace -f -s100 rustup doc |& less

In this case rustup was satisfied with just successfully launching sensible-browser when it actually complained as below and returned 1:

Couldn't find a suitable web browser!
Set the BROWSER environment variable to your desired browser.

• https://github.com/rust-lang-nursery/rustup.rs/blob/master/src/rustup-utils/src/raw.rs#L364

[ghost]

$ time rustup doc

real    0m0.308s
user    0m0.290s
sys 0m0.017s

Exit code is 0.

According to strace, it executed /usr/bin/xdg-open /home/xftroxgpx/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/share/doc/rust/html/index.html The above(xdg-open command) shows elinks (a browser running in console) when I run it myself from xfce4-terminal and it seems to work ok. But with rustup it shows nothing.

Maybe rustup doc could always say the command it executes, so that if it fails, user can copy/paste and manually execute it?

EDIT: using this patch for my own needs.

[Natim]

In my case it tried to open gvfs-open ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/share/doc/rust/html/index.html however the html folder doesn't exists here.

[Natim]

~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/share/doc$ tree
.
├── cargo
│   ├── LICENSE-APACHE
│   ├── LICENSE-MIT
│   ├── LICENSE-THIRD-PARTY
│   └── README.md
└── rust
    ├── COPYRIGHT
    ├── LICENSE-APACHE
    ├── LICENSE-MIT
    └── README.md

I used rustup component add rust-docs to install them and it fixed it!

[nbro]

I was also having this problem on Mac OS X, version 10.13.2. I executed

rustup component add rust-docs

as suggested by @Natim, and then I executed again

rustup doc

and a browser tab automatically opened, in my case, on Chrome, with the offline documentation.

[pickfire]

@Diggsey Maybe you are looking for rustup man?

[britishben]

In my case, it was because I don't have xdg-open installed, and /bin/open is symlinked to /bin/openvt in Ubuntu (referenced here). Maybe require xdg-open as a dependency?

Passing back an error message would be much more helpful than the current behaviour of failing silently.

[ghost]

tl;dr: @britishben set BROWSER env. var. to the browser executable you want rustup doc to open the docs with. (doesn't have to be full path, anything in PATH seems to work too)

---

For me, xdg-open runs elinks(a browser that runs in the text terminal eg. in xfce4-terminal) but when rustup doc tries to execute it, it does so with stdin/stdout/stderr redirected to /dev/null but because stdout is redirected to /dev/null, elinks(in my case) just exits. Perceived result: rustup doc does nothing.

So this does nothing and returns exit code 0: ```bash $ xdg-open "/home/xftroxgpx/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/share/doc/rust/html/index.html" &1 >/dev/null ; echo "exit code:$?" exit code:0 ``` But this works and runs `elinks` just fine(and then I exit with `q` key): ``` $ xdg-open "/home/xftroxgpx/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/share/doc/rust/html/index.html" &1 ; echo "exit code:$?" exit code:0 ```

---

Workaround: set the BROWSER env. var to the browser executable you want rustup doc to run to open the docs with:

;// before:
$ rustup doc
!! executing: xdg-open "/home/xftroxgpx/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/share/doc/rust/html/index.html"

;// after
$ export BROWSER=chro2
$ rustup doc
!! executing: chro2 "/home/xftroxgpx/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/share/doc/rust/html/index.html"

If the BROWSER env. var. points to an invalid/notfound command then it falls back to the list in let commands:

https://github.com/rust-lang/rustup.rs/blob/1dd60c40f7eb8a302ab54cded0e5a2b0d530adeb/src/rustup-utils/src/raw.rs#L371-L385

---

I'm personally still using a [patch](https://github.com/xftroxgpx/a3/blob/313640d85be46b965208255cce6f4ffcadddf280/system/Z575/OSes/3archlinux/on_baremetal/filesystem_now/archlinux/home/xftroxgpx/build/2nonpkgs/rust.stuff/rustup.rs/fix_rustup_doc.patch#L1) to mitigate this instead. (even though `~/.cargo/bin/rustup` gets overwritten upon every successful `rustup update` of the nightly toolchain, or at least it used to(I haven't tried recently); so I'd have to recompile&reinstall my modified `rustup` again :D)

[istankovic]

@xftroxgpx I had the exact same problem and it was quite interesting to see what went wrong. The question is, why does xdg-open try to invoke elinks, even though xdg-settings get default-web-browser returns firefox.desktop?

xdg-open invokes exo-open, as it should, which then proceeds to execute gio-launch-desktop. Now, gio-launch-desktop will read /usr/share/applications/mimeinfo.cache and presumably return the first registered application for the MIME type. In particular, my entry looks like this:

text/html=elinks.desktop;firefox.desktop;

So it seems that as soon as you install another browser, there is a chance that the entry is updated in an unintended way. The cache file is updated by update-desktop-database when a package is installed (I'm using Archlinux). My first thought was that update-desktop-database is adding the entries based on sorted names so that's why elinks.desktop comes before firefox.desktop. However, that seems not to be the case, as evidenced by the updated entry after I installed chromium:

text/html=elinks.desktop;firefox.desktop;chromium.desktop;

I'd love to know what really happened here. Of course, removing chromium will also result in removing the corresponding .desktop entry from the cache file, which hints at one way to work around this rustup issue.

But since we all love elinks and have it installed for a reason, we can just put this:

[Default Applications]
text/html=firefox.desktop;elinks.desktop

into /etc/xdg/mimeapps.list. For user-override, use ~/.config/mimeapps.list instead.

[kinnison]

The mime handlers ought to include information on how to deal with terminal vs. not terminal. I wonder why they don't.

[japrogramer]

my rustup doc --std does nothing

errors.txt

and my miapps
[Added Associations]
text/html=firefox.desktop;elinks.desktop;
application/pdf=firefox.desktop;
x-scheme-handler/http=firefox.desktop;
x-scheme-handler/https=firefox.desktop;
x-scheme-handler/ftp=firefox.desktop;
x-scheme-handler/chrome=firefox.desktop;
text/html=firefox.desktop;
application/x-extension-htm=firefox.desktop;
application/x-extension-html=firefox.desktop;
application/x-extension-shtml=firefox.desktop;
application/xhtml+xml=firefox.desktop;
application/x-extension-xhtml=firefox.desktop;
application/x-extension-xht=firefox.desktop;

[kinnison]

Do you have the rust-docs component installed? (Silly question, but it's possible you might not)

Otherwise this might be another opener bug in which case @Seeker14491 might have some input/questions.

[japrogramer]

yes, i have it installed.

[Seeker14491]

I believe I've figured out what can cause the browser not to open: xdg-open is being ran with a null stdout. Using the lynx browser, links don't open for me. Changing stdout to the default of inherit causes the browser to open properly.

@japrogramer could you share what distro, desktop environment, and web browser combination is not working for you so I can try to reproduce the issue?

[japrogramer]

@Seeker14491 I am using arch Linux, sway wm and Firefox.

[Seeker14491]

I've opened https://github.com/Seeker14491/opener/issues/4 to track this bug.

[jdl]

But since we all love elinks and have it installed for a reason, we can just put this:

[Default Applications]
text/html=firefox.desktop;elinks.desktop

into /etc/xdg/mimeapps.list. For user-override, use ~/.config/mimeapps.list instead.

Thank you. I was going crazy trying to figure out why on only one of my machines when I ran rustup doc it would open Postman.

Sure enough:

$ more ~/.config/mimeapps.list 

[Default Applications]
text/html=Postman.desktop
x-scheme-handler/postman=Postman.desktop

[gdnathan]

up, /usr/bin/xdg-open /home/erudyx/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/share/doc/rust/html/index.html works just fine, but rustup doc or rustup doc --book does absolutely nothing

[Seeker14491]

@Erudyx could you respond to https://github.com/Seeker14491/opener/issues/4#issuecomment-867204711? Also, I'd like to know what's your distro and browser so I can try to reproduce this.

[garasubo]

According to this comment, this issue has been resolved since opener version is now 0.5?

[kinnison]

1.25 is now out