If you have used the Windows Subsystem for Linux, you’re probably aware that it allows you to treat your Windows file systems (mounted under /mnt/c, /mnt/d, etc.) as case sensitive. This means, among other things, that you can create files whose names differ only by case (e.g.
Beginning with Insider Build 17093, we added a method for you to automatically configure certain functionality in WSL that will be applied every time you launch the subsystem. This includes automount options and network configuration.
We’re introducing a file called wsl.conf to handle these configurations.
Starting in Windows Insider build 17093, a WSL application can communicate with a Windows application over Unix sockets. Back in December, we blogged about bringing AF_UNIX to Windows. Now, we’re building on that functionality. Consider a requirement where you want to run some kind of service as a Windows application.
We’ve added new file system features to WSL in Insider Build 17063. You can now set the owner and group of files using chmod/chown and modify read/write/execute permissions in WSL. You can also create special files like fifos, unix sockets, and device files.
Hey WSL users—we have more features to share with you! Our latest Windows Insider build lets you share environment variables between WSL and Windows. Starting with Build 17063, let’s look at how you can leverage the new “WSLENV” to enhance environmental variable interop between Win32/WSL.
I have to provide this guidance at least 2-3 times a day so instead I am publishing it here so everyone can find / link-to this guidance.
There is one hard-and-fast rule when it comes to WSL on Windows:
Along with support for ifconfig & network connection enumeration, Windows 10 Insider Build 14965 delivers a small but important change was made which will enable you more easily invoke Windows tools & applications from within Bash:
Your Windows user environment path is now appended to the WSL path by default.
Moved to a more permanent page!