48

Pretty straightforward, the usual places to figure out the OS you're on seem to be identical to plain Ubuntu on Ubuntu for Windows. For example uname -a is identical to a native GNU/Linux install and /etc/os-version is identical to a Ubuntu Trusty Tahr install.

The only thing I can think of is to check if /mnt/c/Windows exists, but I'm not sure if that's a foolproof idea.

Tim
  • 4,790
  • 4
  • 33
  • 41
DrKabob
  • 481
  • 1
  • 5
  • 3

15 Answers15

47

The following works in bash on Windows 10, macOS, and Linux:

#!/bin/bash
set -e
if grep -qEi "(Microsoft|WSL)" /proc/version &> /dev/null ; then
    echo "Windows 10 Bash"
else
    echo "Anything else"
fi

You need to check for both "Microsoft" and "WSL" per this comment by Ben Hillis, WSL Developer:

For the time being this is probably the best way to do it. I can't promise that we'll never change the content of these ProcFs files, but I think it's unlikely we'll change it to something that doesn't contain "Microsoft" or "WSL".

/proc/sys/kernel/osrelease
/proc/version

And case shall be ignored for grep. In WSL2, /proc/version gives lowercased microsoft.

Atif
  • 345
  • 1
  • 4
  • 16
Gary S. Weaver
  • 7,966
  • 4
  • 37
  • 61
  • 3
    Don't need grep, `if [[ "$(< /proc/version)" == *@(Microsoft|WSL)* ]]; then ...` is faster. – Niklas Holm Jan 11 '19 at 07:58
  • 8
    Commenting to add that in WSL 2 it says "microsoft", all lowercase. – Marc Cornellà Sep 19 '19 at 18:16
  • 1
    Beware! parsing /proc/version, it could contain misleading info (imagine a *gcc compiled by microsoft*). It is better to parse only the kernel release: */proc/sys/kernel/osrelease* – Massimo Aug 26 '21 at 12:11
  • Also beware that it is possible to compile your own kernel for WSL2 (which wasn't the case when the question was originally asked). Assuming that *you* control the environment and can be sure this isn't the case, this answer is fine. If you need to be able to handle the rare corner-case where you don't *know* that WSL is running stock-Microsoft kernel, then additional methods might be warranted like @Massimo proposes. – NotTheDr01ds Aug 26 '21 at 19:40
  • 1
    NB, the `/proc` dir doesn't exist on some *nixes (e.g. OSX), so if you are looking for a portable version of @NiklasHolm's suggestion (i.e. one that won't give an error like `/proc/version: No such file or directory` when the file isn't found, use `if [[ "$(< /proc/version)" == *@(Microsoft|WSL)* ]] &> /dev/null ; then ...` – Joshua Skrzypek Dec 27 '22 at 19:36
24

Updating answer by @per-lundberg:

if [[ -n "$IS_WSL" || -n "$WSL_DISTRO_NAME" ]]; then
    echo "This is WSL"
else
    echo "This is not WSL"
fi

Note: IS_WSL existed in older versions (using lxrun) while WSL_DISTRO_NAME exists in current versions (from Microsoft Store).

iBug
  • 35,554
  • 7
  • 89
  • 134
Shital Shah
  • 63,284
  • 17
  • 238
  • 185
  • logic is reversed, first case is wsl: if [[ ! -z "$IS_WSL" && ! -z "$WSL_DISTRO_NAME" ]]; then echo "You are in wsl!" else echo "You are not in wsl!" fi – Amir T Nov 08 '20 at 19:09
  • This is the fastest and most efficient way to check for WSL. There is no need to really go through grep or read /proc or call external executable file like uname. – Daniel Kim Mar 02 '21 at 15:01
  • 1
    This method is 100% better than the accepted answer because it also works when running a custom compiled kernel under WSL2. Other environment variables that are present are `WSL_INTEROP` and `WSLENV`. – aizimmer Jul 23 '21 at 19:34
  • Mmh I cannot found any environment variable starting with WSL. *WINDOWS 10 20H2 build 19042.1165, UBUNTU 18.04.5 LTS, kernel 5.10.16.3-microsoft-standard-WSL2* – Massimo Aug 26 '21 at 12:07
  • @Massimo - I'm using same Windows build and above works fine. I have env var set as `WSL_DISTRO_NAME=Ubuntu-20.04`. Use command `printenv` to check. – Shital Shah Sep 15 '21 at 19:31
  • While this is useful, `$WSL_DISTRO_NAME` does *not* exist by default for a root user in WSL2. I've tested this in WSL2/Kali, WSL2/Ubuntu 18.04 and WSL2/Ubuntu 22.04. – AJM Jan 26 '23 at 16:01
  • 2
    I didn't know about `$IS_WSL`. I've just tested and it looks like it still exists for a non-root user in WSL2/Kali, but not WSL2/Ubuntu. And not for a root user in any of these WSL2 distros. – AJM Jan 26 '23 at 16:06
  • 2
    @AJM Ah, I was wondering where `$IS_WSL` was coming from -- I don't have it myself, so I wasn't sure why people were pointing to it as a valid variable. In general, that's a *bad* one to use, since it doesn't exist by default in most WSL distributions. Also, `$WSL_DISTRO_NAME` is problematic as well, since it not only won't work for a root user, but for *any* user where the shell is started through PAM. For example, `su - $USER` will create a login session where there is no `$WSL_DISTRO_NAME`. Although this is the highest voted answer, it has a lot of corner cases where it will break. – NotTheDr01ds Jan 30 '23 at 19:52
  • I think this is a -1 from me because even though it's a super useful when it works, it's inherently very unreliable: it requires the distro or user to go out of its way to set it up, and clearing the environment is a fairly normal situation both on purpose (sometimes people do `env - foo` because it's easier than removing a specific environment variable) and on accident (lots of APIs require you to go out of your way to get and pass in the existing environment when executing another program). – mtraceur Mar 28 '23 at 15:49
9

I've been looking for ways to detect that as well. So far I've found 2.

  • /proc/sys/kernel/osrelease is "3.4.0-Microsoft"

  • /proc/version is "Linux version 3.4.0-Microsoft (Microsoft@Microsoft.com) (gcc version 4.7 (GCC) ) #1 SMP PREEMPT Wed Dec 31 14:42:53 PST 2014"

If you just use the Ubuntu distribution installed by default there should be no problems with using them, as they said that it would be unlikely for them to set either to something that doesn't contain "Microsoft" or "WSL".

However, if you were to install a different Linux distribution, I'm pretty sure that the contents of /proc/sys/kernel/osrelease and /proc/version will change, since the distro wouldn't have been compiled by Microsoft.

Adno
  • 203
  • 3
  • 10
  • Because the procfs is emulated by Windows, it should (in principle, as stated on the Github comment) always contain those Microsoft strings, regardless of the distribution used, so the last paragraph seems confused to me. – Guillem Jover Sep 21 '16 at 23:05
  • 1
    @GuillemJover, that depends on whether the hypothetical other distribution is using WSL or not, I guess. I don't know whether Cygwin emulates that functionality, but if it does, I don't imagine it would say Microsoft. (Though I guess the phrase "Microsoft Windows" might appear in the string. I bet "Microsoft@Microsoft.com" won't!) – Harry Johnston Apr 09 '17 at 21:30
  • @HarryJohnston Under Cygwin, `/proc/version` contains a string starting with "CYGWIN_NT", and `/proc/sys/kernel/osrelease` doesn't exist at all. –  May 05 '17 at 01:04
6

I just came up with this for my .bashrc for adding some WSL items to $PATH.

Works in 1703. Not sure if earlier versions.

if [[ $(uname -r) =~ Microsoft$ ]]; then
    foo
fi
Ryan
  • 375
  • 1
  • 3
  • 8
4

Without me doing anything special, these environment variables seem to be set already:

$ set | grep WSL
IS_WSL='Linux version 4.4.0-18362-Microsoft (Microsoft@Microsoft.com) (gcc version 5.4.0 (GCC) ) #1-Microsoft Mon Mar 18 12:02:00 PST 2019'
WSLENV=
WSL_DISTRO_NAME=Debian

So, something like the following snippet should also work in this case (example of what I used it for myself):

if [ ! -z "$IS_WSL" ]; then
    alias code='/mnt/c/Users/per/AppData/Local/Programs/Microsoft\ VS\ Code/Code.exe'
fi

(Note that technically, -z does not check if the variable is unset, merely that it is empty; in practice, this works well enough in this case. The ! at the beginning is there to negate the check.)

Per Lundberg
  • 3,837
  • 1
  • 36
  • 46
3
if [[ `uname -a | grep -i linux | grep -i microsoft`  != "" ]]; then echo "microsoft wsl"; fi;

Or multi-line syntax:

if [[ `uname -a | grep -i linux | grep -i microsoft`  != "" ]]; then 
    echo "microsoft wsl" 
fi

Note: The conditions have to be wrapped in the backticks or it will produce errors such as:

zsh: parse error: condition expected: uname

Anton Krug
  • 1,555
  • 2
  • 19
  • 32
user3073309
  • 184
  • 2
  • 5
2

For WSL2, we can no longer detect through kernel version because it is running an actual Linux kernel in Hyper-V. However, it still can call explorer.exe existing in every Windows installation. So we could...

if [ -x "$(command -v explorer.exe)" ]; then
echo "We are running on WSL"
fi

This should be a more generic way to detect if the script is running on WSL.

Edit: See answers above. I forgot to count Unix-like environments like Msys2 in.

march_happy
  • 420
  • 5
  • 11
  • 3
    wsl2 still uses `Microsoft` title both on `/proc/version` as well as `osrelease` – yekanchi Jul 23 '20 at 19:52
  • +1 This is the best solution, *if* we check for `explorer.exe` at its full absolute path! The environment variable and `/proc` ways are much more fragile to common-enough cases like clearing the environment during an `execve`, or running in a clumsy chroot. The uname approach will penetrate into containers, which is probably not what you want, and requires the kernel to have been mindfully compiled with the right config. But explorer.exe (at an explicit absolute path) is the most likely to only exist on WSL or on a system very deliberately going out of its way to be treatable as WSL. – mtraceur Mar 28 '23 at 16:03
2

I needed to test for macOS in addition to Windows Subsystem for Linux 2.

This is the simplest thing working for us.

if [[ $OSTYPE == darwin* ]]; then
  # macOS
elif [[ "$(</proc/sys/kernel/osrelease)" == *microsoft* ]]; then
  # WSL2
else
  # Other *nix distro.
fi

NOTE: The if order matters. On macOS you get this error when looking at proc/version.
/proc/version: No such file or directory


hat-tip @Niklas Holm and @Marc Cornellà in the top answer's comments for aiming me toward the correct WSL check.

GollyJer
  • 23,857
  • 16
  • 106
  • 174
1

Since the distinction between WSL1 and WSL2 is that the first runs inside a container while the second runs in a virtual machine, we can make use of "systemd-detect-virt --container" to differentiate from both environments.

if [ -n "${WSL_DISTRO_NAME}" ]; then
  # In WSL but which one?
  virt_container="$(systemd-detect-virt --container)"
  case ${virt_container} in
    wsl)
      echo "This is WSL 1"
      ;;
    none)
      echo "This is WSL 2"
      ;;
    *)
      echo "Don't known ${virt_container}"
      ;;
  esac
fi
Jose Sa
  • 21
  • 4
1

A fail-proof test:

grep -qi -- '-WSL' /proc/sys/kernel/osrelease || test -f /proc/sys/fs/binfmt_misc/WSLInterop

Rationale:

  1. Parsing /proc/version is dangerous. It could contain misleading info (imagine a gcc compiled by microsoft). It is better to parse only the kernel release.
  2. WSL2: there aren't any WSL... environment variables. (WINDOWS 10 20H2 build 19042.1165, UBUNTU 18.04.5 LTS, kernel 5.10.16.3-microsoft-standard-WSL2)
  3. In case the test of the kernel release fails, there is a second test.

Note: having two tests, from the first one I removed microsoft and grep only on -WSL. In this simplest form, it is almost fail-proof.

The binfmt_misc template file (to run Windows executables under linux) exists both on WSL and WSL2.

Massimo
  • 3,171
  • 3
  • 28
  • 41
  • 1
    Well, mostly fail-proof. Someone could be pathologic and put a `/proc/sys/fs/binfmt_misc/WSLInterop` on a different distribution :-). And yes, that file still exists under WSL1. – NotTheDr01ds Aug 26 '21 at 19:41
  • And really, you aren't getting any `WSL_*` variables? I thought the distro name was populated by `/init`. I'm also running 19042.1165, but I haven't updated my kernel. – NotTheDr01ds Aug 26 '21 at 19:44
1

Shorter cleaner version of @Shital Shah's answer.

[ -n "$IS_WSL" ] || [ -n "$WSL_DISTRO_NAME" ] && echo 'wsl' || echo 'anything else'
A Merii
  • 574
  • 9
  • 21
1

Lots of answers here over the years, and they'll work most of the time. But every answer here has the potential to return false positives or false negatives in certain situations, and users should be aware of these so they choose the best method for their use-case.

First, IMHO, the method with the best chance. That is, it is unlikely to return a false positive or a false negative:

  • The presence of /proc/sys/fs/binfmt_misc/WSLInterop is a pretty good indicator that you are on WSL. This may be the most reliable method, and it is what Ubuntu's Snapd project uses as its detection mechanism. 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: 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 ;-)

  • A close second, to me, is checking for the presence of both the strings "Microsoft" and "WSL" in the kernel name. This can be done most easily on a Systemd distribution (even without Systemd being enabled) using:

    [[ "$(systemd-detect-virt --container)" -eq "wsl" ]] && echo "WSL" || echo "Not WSL"
    

    On both WSL1 and WSL2, this returns command returns wsl. The source shows that it uses checks the kernel name for the strings "Microsoft" and "WSL". It also references this Github comment from the WSL lead recommending the technique.

    As far as reliability goes, it would be pathologic for someone to create a kernel with those names that wasn't intended to be used with WSL, so it has a very low chance of presenting a false positive.

    However, it is entirely possible to compile your own kernel for WSL2, and there's no guarantee that you will name it with "Microsoft" and "WSL". In fact, I tend to name mine differently so that I know I'm not using the stock WSL2 kernel. This will create a false negative for the above check. And while you might think you'll remember this, it can be a pain to troubleshoot things like this when you forget that you have a custom kernel installed (I speak from experience).

    Note that uname -a, /proc/version, and other similar checks are just a variation on the test above, with the same caveats. Note that there nine answers here (10 with mine) that use some variation of this technique already, so please, if you are going to add another, make sure it is truly unique ;-).

Credit goes to @Massimo's answer for combining the above two methods into what is probably the best existing answer here. It probably just needed some more explanation on why it's an improvement.


Other methods and their corner cases:

  • Relying on $WSL_DISTRO_NAME has two issues:

    • It won't exist for a root user.

    • It won't exist in any shell started through a PAM login. For instance:

      $ [[ -n $WSL_DISTRO_NAME ]] && echo "WSL" || echo "Not WSL"
      WSL
      $ su - $USER
      # login
      $ [[ -n $WSL_DISTRO_NAME ]] && echo "WSL" || echo "Not WSL"
      Not WSL
      

    So there's a rather high chance of receiving a false negative. On the other hand, creating a false positive by falsifying a $WSL_DISTRO_NAME variable would be pathologic.

  • Relying on $IS_WSL is just plain wrong. That's a variable that is set by Kali Linux only and does not exist in most WSL distributions, including the default Ubuntu installation.

  • Testing for the presence of some known executable (such as wsl.exe or explorer.exe) has the following potential problems:

    • Interop can be disabled. However, if you are doing this on your own system, then you'll know whether or not this is the case. If you are trying to create a script which will run on other users' systems, then you probably won't want to use this due to the chance of false negatives.

    • Interop can fail under certain scenarios. For instance, similar to the $WSL_DISTRO_NAME above, a su - $USER will create a PAM login session where the Interop will not work.

NotTheDr01ds
  • 15,620
  • 5
  • 44
  • 70
  • A great answer and +1 from me, though I would argue that it is actually better to check for `explorer.exe`/`wsl.exe` at its *explicit absolute path* (see my comment on that answer, but basically I think the false positives and false negatives of this are most likely to be intentional by the caller or correspond to the environment behaving relevantly WSL-like or not), unless you specifically want your code to think it's on WSL even when it's running in a container (if you do, then I think this answer is the best, since `/proc` is very likely to be visible in a container). – mtraceur Mar 28 '23 at 16:13
0

Here's what I put in my .bashrc

if [[ $(uname -v | sed -rE 's/^#[0-9]{3,}-(\S+).+/\1/') == "Microsoft" ]]; then
  # WSL-specific code
fi
  • uname -v gets the kernel version in the format of #379-Microsoft Wed Mar 06 19:16:00 PST 2019 and the sed expression pulls out the Microsoft string.
Dan
  • 1,805
  • 2
  • 18
  • 21
0

If you in Bash and want to avoid fork:

is_wsl=0
read os </proc/sys/kernel/osrelease || :
if [[ "$os" == *Microsoft ]]; then
  is_wsl=1
fi
gavenkoa
  • 45,285
  • 19
  • 251
  • 303
0

Windows Subsystem for Linux 2 (WSL 2) in Windows 10 Pro Insider Preview Build 18917

/proc/version contains:

Linux version 4.19.43-microsoft-standard (oe-user@oe-host) (gcc version 7.3.0 (GCC)) #1 SMP...

gregln
  • 1
  • 1