wsl.exe <command>
Note:
- Use the same working directory as the current CMD or PowerShell prompt.
- Run as the WSL default user.
- Have the same Windows administrative rights as the calling process and terminal.
- The commands passed into wsl.exe are forwarded to the WSL process without modification. File paths must be specified in the WSL format.
Examples:
C:\temp> wsl ls -la
<- contents of C:\temp ->
C:\temp> wsl sudo apt-get update
[sudo] password for username:
Hit:1 https://archive.ubuntu.com/ubuntu xenial InRelease
Get:2 https://security.ubuntu.com/ubuntu xenial-security InRelease [94.5 kB]
C:\temp> wsl ls -la | findstr "foo"
-rwxrwxrwx 1 root root 14 Sep 27 14:26 foo.bat
C:\temp> dir | wsl grep foo
09/27/2016 02:26 PM 14 foo.bat
C:\temp> wsl ls -la > out.txt
C:\temp> wsl ls -la /proc/cpuinfo
-r--r--r-- 1 root root 0 Sep 28 11:28 /proc/cpuinfo
C:\temp> wsl ls -la "/mnt/c/Program Files"
<- contents of C:\Program Files ->
[binary name].exe
Note:
- Retain the working directory as the WSL command prompt.
- Have the same permission rights as the WSL process.
- Run as the active Windows user.
- Appear in the Windows Task Manager as if directly executed from the CMD prompt.
- Windows path is included in the Linux
$PATH
. - Windows binaries must include the file extension, match the file case, and be executable.
- Modifying files located on VolFs (files not under
/mnt/<x>
) with a Windows application in WSL is not supported. - WSL tries to keep the working directory of the Windows binary as the current WSL directory, but will fall back on the instance creation directory if the working directory is on VolFs.
Examples:
$ notepad.exe
$ ipconfig.exe | grep IPv4 | cut -d: -f2
172.21.240.1
10.159.21.24
$ ls -la | findstr.exe foo.txt
$ cmd.exe /c dir
<- contents of C:\ ->
$ cmd.exe /C dir
<- contents of C:\ ->
$ PING.EXE www.microsoft.com
Pinging e1863.dspb.akamaiedge.net [2600:1409:a:5a2::747] with 32 bytes of data:
Reply from 2600:1409:a:5a2::747: time=2ms
$ notepad.exe "C:\temp\foo.txt"
$ notepad.exe C:\\temp\\foo.txt
C:\temp> wsl
/mnt/c/temp/$ cd ~
~$ notepad.exe foo.txt
~$ ls | grep foo.txt
~$ exit
exit
C:\temp>dir | findstr foo.txt
09/27/2016 02:15 PM 14 foo.txt
WSL and Windows share WSLENV
, a special environment variable created to bridge Windows and Linux distros running on WSL.
Flags:
/p
- translates the path between WSL/Linux style paths and Win32 paths./l
- indicates the environment variable is a list of paths. In WSL, it is a colon-delimited list. In Win32, it is a semicolon-delimited list./u
- indicates that this environment variable should only be included when running WSL from Win32./w
- indicates that this environment variable should only be included when running Win32 from WSL.
Examples:
Note:
- It is shared; it exists in both Windows and WSL environments.
- It is a list of environment variables to share between Windows and WSL.
- It can format environment variables to work well in Windows and WSL.
- Flags can be combined as needed.
- It is a colon-delimited list of environment variables that should be included when launching WSL processes from Win32 or Win32 processes from WSL.
- It can be set in .bashrc or in the custom Windows environment for your user.
- A user sets its value to a concatenation of several other already-defined environment vars.
- In WSL, the definition (via .profile or other) will override the value defined in
WSLENV
when accessed via WSL. - In Win32, the
WSLENV
definition will override the value previously defined.
It is recommended to append the environment variable that needs to pass to the process to WSLENV
. This is to avoid accidentally wipe out the other vars previously set for WSLENV
.
#!/bin/bash
#some logic here... export MYPATH=/mnt/c/Users/ #invoke the process and pass the env var in one go WSLENV=$WSLENV:MYPATH/p process.exe