1. Are our workarounds still required on WSL2? Personally I'd love to just handle that as linux, basically anything we have to do specifically for it should be a bug there as I understand WSL's purpose. (also is WSL1 now dead or still a thing?)

2. That's not the only place we do that check, see also

   fish-shell/share/functions/help.fish

   Line 83 in e51f4e5

   and string match -riq 'Microsoft|WSL' </proc/version

   and

   fish-shell/src/common.cpp

   Line 172 in e51f4e5

   if (std::strstr(info.release, "Microsoft") != nullptr) {

   .

If we treat wsl2 as linux, "webbrowser.open(fileurl)" is called. But a url like "file:///home/xxx/" doesn't work under wsl2.

also is WSL1 now dead or still a thing?

WSL2 is not officially out yet as far as I know. And even if it was, people will still be on WSL1 for a while. At least I will, since updates are controlled by company IT and they're slow at rolling out new versions of windows

The "broken" versions referred to in the common.cpp check are still in support (until November 2020), and the WSL check is still needed to block .dll files from completion (a9b582d).

Okay, so if a check for lowercase "microsoft" works here as well, should we just change that everywhere?

Mind that the checks are typically case-sensitive.

The utsname.release on wsl1looks like "4.4.0-18362-Microsoft" (windows 1903 (18362)).
But on wsl2, it looks like ”4.19.84-microsoft-standard" (with windows 2004 (19041)).
Discussions can be found here. How to tell in Linux under WSL if using WSL1 vs WSL2 ?
I am sorry that my patch using lowercase only works for wsl2. I will change it to check both cases.

@faho I have checked the files common.cpp and help.fish. They don't need to change.
The problem is fish_config falis to start on wsl2. And the workarounds can be applied only in this file.

Yes, sounds good; the common.cpp check is another issue which doesn't need to block the merging of this patch.