-
Notifications
You must be signed in to change notification settings - Fork 822
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
Feature: /etc/windows-release #2299
Comments
@mcandre - Thanks for the suggestion. Interesting idea, but can also feels like a dangerous proposition for compatibility. We don't want to encourage any packages taking a dependency on this and introducing WSL specific behavior, that can also hide bugs in WSL. |
It was brought up last year that it should be in Sunil, people are going to take WSL dependencies in their software. Because there are WSL dependencies. Take for example this patch to Meteor here, which works around #1529 (an issue that did not even rate a "that's going to be really hard to fix" response from anyone). So people Anyway, from a
|
I agree with @therealkenc. Running systeminfo.exe or ver.exe via interop is probably the right way to go. |
Another example of a WSL-specific fix: eventlet/eventlet@09e166b On a side note, maybe they should be collected at some location for future in order to inform those developers when WSL oddities get fixed (e.g. in order to prevent workarounds causing problems once WSL follows the behavior of an original Linux™, we've been there with IE). |
Even more amusing is glibc-wsl, which works around #1878 by rolling back this commit. That is, if one is willing to put "Cygwin for WSL" on the table, you can fix all kinds of stuff 😏. |
|
or otherwise a |
The Windows version is now part of /proc/version.
|
As an aid to scripts attempting to determine the nature of the runtime environment with
cat /etc/*release*
, could bash on Ubuntu on Windows include a/etc/windows-release
or similar file?The text was updated successfully, but these errors were encountered: