seeker14491 / opener

Open a file or link in the system default program.

Opener

This crate provides the ability to open a file or link with the default program configured on the system.

See the docs for more details:

Docs

License

Licensed under either of

• Apache License, Version 2.0 (http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (http://opensource.org/licenses/MIT)

at your option.

Third party software

See LICENSE-THIRD-PARTY

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

opener's Issues

Browser doesn't open on WSL2

Hi, I came to this library when debugging why cargo doc --open doesn't actually open the web browser on Windows Subsystem for Linux 2 (WSL2). I've reproduced the issue by doing the following in this repository:

1. Get a path to a html file . I use the html file generated by cargo doc
2. cargo run <path_to_html>
3. The application prints "Opened path successfully." but nothing happens.

Manually running the xdg-open bundled in this repo gives:

❯ opener/src/xdg-open /home/ryan/Programming/External/opener/target/doc/opener/index.html
Start : This command cannot be run due to the error: The system cannot find the file specified.
At line:1 char:1
+ Start "/home/ryan/Programming/External/opener/target/doc/opener/index ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOperationException
    + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand

It looks like it might be invoking the windows start command somehow. Unsure what mechanism makes this happen.
The return code is 0, indicating a success, yet clearly the command failed.

I am on WSL2, and running Ubuntu 20.04. I do not know if the problem also occurs on WSL1 or not. Note that the BROWSER environment variable is empty.

The expected behavior would be to fail the command, since it does not complete successfully, or better yet, open the file in the windows web browser and translate the path.

opener::OpenError should implement std::error::Error

Right now, OpenError only implements Fail. This works great for Cargo, which is a consumer of opener, and uses the failure crate.

I'm looking at using opener for the same functionality in rustup, which uses error-chain instead. To support this (and other consumers not using failure), OpenError should implement std's Error trait.

I'll go ahead and make a PR since it's an easy fix.

Browser not opening on Linux

Under certain conditions, nothing happens when trying to open a website using opener::open, while manually using xdg-open works fine. I suspect this is due to spawning the command with a null stdout. This is the current code where the command is configured:

let mut cmd = Command::new(cmd)
        .args(extra_args)
        .arg(path)
        .stdin(stdin_type)
        .stdout(Stdio::null())
        .stderr(Stdio::piped())
        .spawn()?;

The reason null stdout was used was to prevent polluting the user's terminal with output from xdg-open.

Not enough context in error messages

Some users have reported issues with using cargo on WSL where they cannot open the documentation. There are a fair number of distributions in the Microsoft Store that do not preinstall wslview. The error message is a rather difficult one to understand:

warning: couldn't open docs

IO Error

Caused by:
  No such file or directory (os error 2)

It would be helpful if the error message could provide some more context. Particularly that it is the wslview executable that cannot be found (and maybe even some more help on what to do about that). Perhaps there could be more variants of OpenError for specific errors like these?

Anytime Command.spawn is used, it might be good to wrap that error with information about which command is being executed.

published crates don't contain license texts but only contain bogus symlink

It looks like the symlinks that were added in order to include license files in published crates don't work correctly.
I downloaded sources for opener v0.5.0 and v0.5.1 from crates.io, and in both cases the files are bogus - LICENSE-APACHE is a file that contains the string ../LICENSE-APACHE, etc.

If you are running "cargo publish" on Windows, I think symlinks do not work for this purpose, and as far as I know, adding full copies of these files is the only way to work around the fact that symlinks don't really work on Windows. :(

Open in named tab for URL

Use case is to name a tab that opener opens in, so I can call it again with the same tab name and have the page reloaded in the same tab instead of opening a new tab.

please include LICENSE files into the repo and all crates

It is basically legal requirement of ASL 2.0/MIT and it would help us to package opener for Fedora.

Thanks in advance!

0.4 doesn't seem to use either BROWSER or the default-browser from XDG.

rustup-doc version 1.24.3 (the current latest available version as of the filing of this issue) uses opener = "0.4.0", and neither the BROWSER environment variable nor the XDG default-browser property appear to be used to open the browser. Following the discussion in rust-lang/rustup#2642, it appears that support for the BROWSER environment variable isn't available with that version of opener. Looking at the 0.4.1 tag in this repository (and based on the discussion in the aforementioned issue), it appears that xdg-open should be used to open the URL. This doesn't seem to be the case.

➜ echo $BROWSER
qutebrowser
                                                                                                                        

➜ xdg-settings get default-web-browser
org.qutebrowser.qutebrowser.desktop


➜ rustup doc &
[1] 918976


➜ pstree 918976
rustup───sh───chromium─┬─chromium───chromium───19*[{chromium}]
                       ├─chromium───chromium─┬─chromium───5*[{chromium}]
                       │                     └─2*[chromium───12*[{chromium}]]
                       ├─chromium───7*[{chromium}]
                       └─19*[{chromium}]

Switch the backend on Linux (and WSL) from xdg-open to handlr

It seems that xdg-utils is not actively maintained. A lot of issues are unresolved and PRs are not responded.

rustup relies on this crate to open the local documentation, since xdg-utils is not actively developed, which is not good for rustup, we probably could switch the backend to handlr:)

On macOS, `opener` uses Safari where as the `open` command uses Firefox

When running code from cargo run in VS Code, the opener::open() call when provided with a URL will open that URL in Safari. If I run open from the command line in the same shell, it opens in Firefox.