21

In .bashrc, I have some configuration for specific environments like this.

if [ "$(uname)" = 'Linux' ]; then
   . "$HOME/.bash.d/ubuntu"
fi

if [ "$(uname)" = 'Darwin' ]; then
   . "$HOME/.bash.d/osx"
fi

To know whether the current environment is under WSL, I use the /etc/wsl.conf file that normally only exists in WSL.

if [ -f "/etc/wsl.conf" ]; then
   . "$HOME/.bash.d/wsl"
fi

But of course, the file can also exist in other environments.

How should I check if the current environment is running in WSL?

Improve this question
2
  • 3
    /etc/wsl.conf doesn't exist on my WSL. Commented Oct 28, 2022 at 15:17
  • @DonaldDuck Yes, that's partly why the OP is asking this question 😉! The file may or may not exist. For the OP, it's always used on their WSL systems for configuration purposes, but it doesn't exist by default. However, it would be easy to accidentally create a /etc/wsl.conf on a pure-Linux system, causing false-positives. So the OP was asking for better options. Commented Oct 29, 2022 at 14:40

6 Answers 6

Reset to default
27

Recent WSL Releases: wslinfo

In recent WSL releases, the wslinfo command has been added and can be used to check certain features of WSL from within the running distribution. There are several different features that can be used here:

  • In WSL pre-release 2.0.4, the /usr/bin/wslinfo command was added with the --networking-mode switch. /usr/bin/wslinfo is always a symlink to the WSL-injected /init. You can:

    • Check for the binary and whether it is a symlink.
    • Run the wslinfo --networking-mode command and confirm a non-zero exit code.

  • In WSL pre-release 2.2.3, wslinfo --wsl-version was added, which will report the WSL version number. This can also be used, not just to check whether we are inside a WSL distribution, but also (obviously) the version number.

  • Sometime between 2.2.3 and 2.6.0 (the first open-source release of WSL), --wsl-version was deprecated (it is still available), and wslinfo --version was added. Unfortunately, the addition of the --version switch was never (that I can see) documented in the release notes, so it's tough to tell how far back it goes.

(credit and thanks to @ironsand for suggesting the wslinfo command via original edits)

Plan9

Ironically, three years later I'm noticing that a few minutes after I wrote this answer originally, I answered another question here) about the plan9 process. This is also a symlink to /init, as with wslinfo, and can probably be used in a similar way (check the existence of the binary and symlink) for much older releases.

Other methods for older releases

Each of these detection methods could cause false-positives or false-negatives in certain situations. That said, if you are just doing this for your personal config files, then you probably have a pretty good idea about whether a given method will work for your system or not.

Some various methods, with their pros and cons:

  • The presence of /proc/sys/fs/binfmt_misc/WSLInterop is a pretty good indicator that you are on WSL. This is what Ubuntu's Snapd project used as its detection mechanism at one point (it may still). This file exists under both WSL1 and WSL2 by default. Even when Interop is disabled via /etc/wsl.conf, this file will still be created by WSL at startup.

    Caveats:

    • The use of Systemd in WSL can in some situations reset the binfmt entries and suppress the creation of this file.

    • Of course, a binfmt_misc entry could be set up with the name WSLInterop, but that would be extremely pathologic, leading to a false-positive test.

      Also, it is possible to override the name of the Interop, as mentioned in my Ask Ubuntu answer here. This would be an unusual case, but we used it to thwart the Snapd WSL detection temporarily while a bug was being fixed. This creates a false negative, of course.

      In a war of escalation, you could "thwart-the-thwarting" by grepping for the magic 4d5a in that directory, but that might be going a bit far ;-)

  • As @MBehrens mentions, the default kernel name under WSL contains the string "Microsoft" (or "microsoft", depending on the release). Using uname -r or /proc/version) can be used for detection.

    Caveats: Other systems may (I'm thinking Azure) use a Microsoft-built kernel, which could create a false positive. And it's possible to build a custom kernel for WSL2 with a different name, which would create a false negative.

  • You could even just check for the environment variable $WSL_DISTRO_NAME. This variable is injected into the WSL environment automatically.

    Caveats: You could always (pathologically) create this variable name on any system, leading to false positives.

    More importantly, there are cases when this variable will not be available, such as if you su - $USER.

There are certainly more (e.g. see if $(which powershell.exe) is executable), but the above should give you some idea of the various approaches.

Improve this answer
5
  • as somebody who most of the time compiles his own kernel, i second the warning for point 2. Other approach: can't u just check whether u can access filepath C:\ ??? WSL should have all native windows commands and paths. might aswell check for cmd-command Commented Oct 28, 2022 at 18:35
  • @clockw0rk Sort of, C: doesn't quite work since it's /mnt/c in WSL, but that mount can (a) be easily changed by /etc/wsl.conf or (b) disabled entirely using the same. And yes, cmd.exe, powershell.exe (mentioned as one of the "more" options in the last line), notepad.exe ... all could be used, but only if Interop isn't disabled. If it is, then that method won't work either. Commented Oct 29, 2022 at 17:46
  • In WSLv2 with any of the Kali, Ubuntu 18.04 or Ubuntu 22.04 distros, which powershell.exe works for a normal user, but not for a user who's just become root with sudo su. Commented Feb 1, 2023 at 16:35
  • @AJM Sure, clearly I didn't go into the caveats on the "certainly more" section. There are false positives and negatives with every option. If $(which powershell.exe) was without issue, it would have been listed as a better option ;-). Commented Feb 1, 2023 at 17:43
  • @ironsand Thanks for the pointers on wslinfo - As you can see in my revision, I'm not convinced that wslinfo --version is supported back to 2.0.4 (GitHub release-note indications are it is much more recent), but if you have additional info on that, please let me know - Thanks! Commented Sep 4, 2025 at 22:18
12

Check the output of

cat /proc/version

and

cat /proc/sys/kernel/osrelease

For example:

if [[ $(grep -i Microsoft /proc/version) ]]; then
echo "Bash is running on WSL"
fi
Improve this answer
2
  • 1
    I made a slight edit since the string can be either "Microsoft" or "microsoft" depending on the WSL version. Also note that this will work for most users, but WSL2 can use a custom kernel, and there's no requirement that kernel name includes that string. Commented Oct 27, 2022 at 11:48
  • Note that this is the same method used by systemd-detect-virt (although they check for both "Microsoft" and "WSL": github.com/systemd/systemd/blob/… Commented May 12, 2025 at 19:21
8

If you have systemd enabled you can try

systemd-detect-virt

this should return

wsl
Improve this answer
1
  • 1
    For those curious, systemd-detect-virt is just checking if /proc/sys/kernel/osrelease contains "Microsoft" or "WSL". See github.com/systemd/systemd/blob/… Commented May 12, 2025 at 19:16
1

A bit late to the party but under WSL the command lscpu shows a line:

  • Hypervisor vendor: Windows Subsystem for Linux

It does this as both an ordinary user and under sudo su .

Improve this answer
1
  • 3
    To me, this does output Hypervisor vendor: Microsoft. Commented Jun 6, 2023 at 7:20
0

WSL has its own kernels - when one runs uname - it'll show a MS specific kernel that shows its WSL2

uname  -r 
5.15.153.1-microsoft-standard-WSL2
Improve this answer
1
  • Care to elaborate your answer? This does not seem like it will age well. Commented Sep 24, 2024 at 22:52
0

I may be very late here. In recent versions of WSL (WSL version: 2.6.1.0), we have certain environmental variables available for the logged in user. These are:

  • $WSL2_GUI_APPS_ENABLED
  • $WSLENV
  • $WSL_DISTRO_NAME
  • $WSL_INTEROP

These variables can be also be tested to check if we are in wsl linux or not.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.