search

Seeker14491 / opener

Open a file or link in the system default program.
Apache License 2.0
49 stars 10 forks source link

Browser doesn't open on WSL2 #8

Closed TheButlah closed 3 years ago

TheButlah commented 3 years ago

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.

eugene-babichenko commented 3 years ago

From what I can see, the problem is that this crate is using Process::spawn to run the program. On top of that stdout for that program is set to Stdio::null(). The whole combination leads to the situation when the exit status would be ok even if the xdg-open script fails just because it was spawned successfully. This also leads to inability to run a text-mode browser under certain configurations, because it will have no tty to work with and will exit immediately.

To be completely correct it might be useful to change the script in such a way that it spawns GUI applications, runs CLI apps in foreground and exits if it is incapable of opening the provided path. And obviously use Process::output instead of Process::spawn. That's the rough idea.

Seeker14491 commented 3 years ago

This should now be fixed in the 0.5 release.