Implement wsl compatibility

[Nachtalb]

The possible ways I found:

• cmd /c start URL ==> https://github.com/cpbotha/xdg-open-wsl/blob/7d40d572d0274db4b668b5d42797ebd3d8e16885/xdg_open_wsl/xdg_open_wsl.py#L191
• powershell.exe Start URL ==> https://github.com/4U6U57/wsl-open/blob/6419bb63845acd0533f30bdc8258f8df5fbb25cb/wsl-open.sh#L18
• wsl-open various tools that call themselves that act as a replacement for xdg-open and may have more methods than the 2 above.

⚠️ A problem exists with the fallback chain, which may lead to problems in WSL environments or similar #57. Consider this during testing (there are proposed solutions in the issue) ⚠️

[amodm]

Thanks @Nachtalb, for adding to the platform support. My only question about this is - can is_wsl be implemented via presence of an environment variable instead of looking up a proc file?

[Nachtalb]

@amodm

Thanks @Nachtalb, for adding to the platform support. My only question about this is - can is_wsl be implemented via presence of an environment variable instead of looking up a proc file?

There seems to be a "WSL_DISTRO_NAME" env var injected by WSL though it is not enforced and not available in every environment:

microsoft/WSL#5914

IMHO checking for /proc/version is safer as one would have to specifically build a custom kernel to get the same outcome on a non-wsl system. It also seems to be a semi-standard way of checking for WSL in general.

microsoft/WSL#4071 (comment)
https://stackoverflow.com/questions/38086185/how-to-check-if-a-program-is-run-in-bash-on-ubuntu-on-windows-and-not-just-plain/43618657#43618657

[amodm]

Ok. I'm comfortable with the current determination of WSL env.

Another question I have is: this doesn't really fix #57, does it? I'm talking about the scenario where xdg-open is available, but fails to execute. Have you tested this PR in the WSL envs you mention in #57, and verified it to work?

[Nachtalb]

Ah no it doesn't fix it. This would just be a implementation for wsl like the rest of the custom opener implementations. #57 is an entirely different problem, I just used the wsl as a case where the problem might occur.

[amodm]

Ah, ok. I'll be keeping this PR on hold until I've figured out a good way to handle that, because otherwise we can't declare effective WSL compatibility. I'll be merging this PR right after I've figured out an answer.

[amodm]

@Nachtalb, sorry about the delay here. I got WSL2 setup & running, and found that with wslu installed, the code on current main works fine. Without it, it fails.

Should I look at this PR as supporting WSL independent of wslu? If yes, is that a common enough scenario? If no, then I'd rather debug any bugs on WSL that's preventing this crate from working alongside wslu.

Thanks for helping me develop a better understanding of the WSL ecosystem. I'm not familiar with it enough to answer the above question on my own, so relying on your expertise here.

Ignore this 👆🏼. The fact that my WSL2 installation did not contain wslu by default, should be sufficient reason to merge this PR. There are some additional changes I'll need to make, for this implementation to comply with Consistent Behaviour, but I'll make them separately post this merge, as I modified the Consistency definition after this PR was created.

I've merged this PR locally. I'll be pushing to Github after I've made the changes for Consistent Behaviour, post which this PR would reflect as merged on Github.

[amodm]

@Nachtalb, this is now merged, with the following additional changes:

1. Modified mechanism of is_wsl() to be determined by presence of enabled in /proc/sys/fs/binfmt_misc/WSLInterop. As per the doc, if this is disabled, then we anyways cannot invoke windows programs from linux. wslu seems to be doing the same.
2. Currently limited to opening only http(s) urls, as file:// urls require some extra handling. Hopefully, I'll find time to build that in before the upcoming v0.8.3 release.

I've tested it on a sandbox WSL setup, both with and without wslu installed, and it seems to work. Can you please give it a shot as well? All the more important, because tests for WSL is not yet automated. You can test for this by including the following in your Cargo.toml

[dependencies]
webbrowser = { git = "https://github.com/amodm/webbrowser-rs" }

[Nachtalb]

• Modified mechanism of is_wsl() to be determined by presence of enabled in /proc/sys/fs/binfmt_misc/WSLInterop. As per the doc, if this is disabled, then we anyways cannot invoke windows programs from linux. wslu seems to be doing the same.

Nice! I didn't know that.

I've tested it on a sandbox WSL setup, both with and without wslu installed, and it seems to work. Can you please give it a shot as well? All the more important, because tests for WSL is not yet automated. You can test for this by including the following in your Cargo.toml

I will do that once I am on my PC.

[amodm]

@Nachtalb, this is now out as v0.8.3