New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WSL detection is set based on build system, which is often Real Linux™ #5619
Comments
That file/value is currently checked at compile-time to make it a no-op at runtime. After that implementation was coded up it was pointed out in #5115 (comment) that with the current method of package management in use on most WSL-installed distros, it would not suffice. |
I think we're going to want to go back to actually checking the /proc entry. |
Just a call to |
Do you want this for 3.0.1? |
Added it to the release notes instead. |
Sorry @zanchey, it was a very busy weekend to cap off of a very busy week for me. |
Found #5298 after spending quite some time tracking down why fish (3.0.0) was giving me "Could not send own process..." pipe errors on my Windows 10 WSL install (1803). However, the issue states that a message was added to instruct people to upgrade to "Windows 10 1809/17763 or higher". I never got this message. Looking at the code on the master I see this:
The definition of
is_windows_subsystem_for_linux()
shows this:The comment states that it is going to inspect /proc/sys/kernel/osrelease to determine if fish is running on WSL. But when I scan all of the files in the project I find nothing that does this inspection and the only way the "WSL" is set is if fish was built using cmake on a WSL machine. I tested this and it does print the error if you build it that way, but that's an unlikely scenario for most users of WSL.
fish, version 3.0.0-309-gc7656e66
Linux MYHOSTNAME 4.4.0-17134-Microsoft #523-Microsoft Mon Dec 31 17:49:00 PST 2018 x86_64 x86_64 x86_64 GNU/Linux
xterm-256color (WSL default terminal)
The text was updated successfully, but these errors were encountered: