Command Prompt / Console / Windows Subsystem for Linux (WSL)

Greetings from the Windows Command-Line Teams, including the Windows Console and Windows Subsystem for Linux (WSL) teams!

We’re hear to learn about the features you’d like to see in the Windows Console (the terminal app itself), Cmd and PowerShell shells, and the Windows Subsystem for Linux (WSL) upon which several Linux distros now run!

It's great that I can mount file systems or USB devices through drvfs but these mounts don't persists when all Linux shells are closed.
How does one mount filesystems permanently, say through /etc/fstab ?
Surely it shouldn't be necessary to manually mount filesystems after the last Linux shell has been closed and a new is invoked.

Bash on Windows will automatically mount drive C: under /mnt/c. But other drives (D:, E:, etc.) remain inaccessible to bash. Those drives may be hard drives, SSDs, DVD drives, USB thumb drives, or network mapped drives. For bash to be usable as a development environment these other drives need to be accessible. It would be ideal if they were mounted dynamically without any additional action required by the user. For example, if the user types the following:

net.exe use * \\remote_machine\c$

Then whatever drive gets assigned (ie. Z:) should be automatically mounted in bash (ie. under /mnt/z).

I would love to have the ability to access raw partitions on my hard drive (provided that WSL is stable and will not obliterate my data) and also have the ability to mount filesystems not natively supported under Windows such as ext4, and btrfs among others. Specifically, I want to be able to mount partitions on my hard drive that I have windows installed on.

After general mount support is added, allowing "network drive" mounts through the mount command and the /net automounter would make it straightforward to integrate a Windows dev machine into a mainly *nix network.

Since the last year I've been using ReFS a lot to store my data and I loved it so far. I am unable though to use apps that rely on different ownership of files that are stored in my ReFS partitions and especially those that won't run as root.

In order to do so we need metadata option when mounting ReFS volumes to perform simple chown operations.

Add Posix ACL support to WSL and for drvfs mounts derive them from Windows ACL. It is possible to map Posix ACLs to Windows ACLs with some limitations. That would greatly enhance interoperability between windows applications and wsl applications. Using metadata to save posix permissions on drvfs mounts greatly reduces interoperability, since windows applications are not aware of posix permissions saved as metadata.

For example on my cygwin install I switched from /cygdrive/c/ to just /c/ to be more compatible with git (for win32) bash sessions and easier to type.

It would be great if we could control where the WSL subsys mounts the windows drives, so people can use anything they want that makes their life easier, instead what for now seems to be magically hard wired /mnt/c (which is a sane default path BTW)

In conjunction with the request for ext4 mount support, chrooting into existing installations instead of deploying a new distro install in WSL would be a great addition to the upcoming multi-distro support.

I currently have a Linux desktop, which I mainly use to create test packages for use on server-type systems with specialized hardware, i.e., the test packages I create cannot run on my Linux desktop. Creating these test packages requires access to some file servers in order to copy needed files, a few of which are executable. Using WSL would very nearly allow me to get rid of my Linux desktop, except it can't distinguish files on the server that have the execute permission set from those that don't.

Alternatively, I could copy most of the files I need using our source code manager to WSL's root drive, but then I would lose the ability to edit files with a GUI editor such as Visual Studio Code, since you cannot use Windows apps to modify files on WSL's root drive. Additionally, I would not have access to these files if my Windows 10 system is not accessible.

Please add this feature to WSL at your earliest convenience, as it would greatly simplify my work flow and allow me to consolidate all my work that doesn't actually involve using specialized hardware to my Windows system.

I currently have a Linux desktop, which I mainly use to create test packages for use on server-type systems with specialized hardware, i.e., the test packages I create cannot run on my Linux desktop. Creating these test packages requires access to some file servers in order to copy needed files, a few of which are executable. Using WSL would very nearly allow me to get rid of my Linux desktop, except it can't distinguish files on the server that have the execute permission set from those that don't.

Please add FUSE (Filesystem in Userspace) interface /dev/fuse into WSL (Windows Subsystem for Linux).
With FUSE, we can access from WSL to file storages regularly used with Linux cluster environments such as GlusterFS, Moose FS, etc.

Can not run nmap from WSL due to inability to interface with network sockets. Please enable passthrough or provide documentation / support to allow configuration of ethernet sockets to work with nmap. Was lead here by this discussion: https://github.com/Microsoft/WSL/issues/2039

It would be nice to have (relatively) easy access to the dedicated GPU's on our Win10 PC's, and OpenCL support for the AMD Drivers & CUDA for NVidia drivers etc.

What I am thinking on specifically (although there are many many uses for it and CUDA support) is hashing functions that are lackluster within windows itself, but benefit immensely within Linux and Unix.

Cryptocurrency mining for example, is known to be much faster on Linux systems than Windows. Do you see any support for OpenCL and/or CUDA in the future?

I am stuck using a MAC at work because the terminal is far superior. with Linux/MAC I can open multiple tabs in the terminal, with windows WSL I have to open a bunch of windows. Sometimes I will has 7 or 8 tabs open at once... Adding tabs to the command terminal would be an excellent upgrade. I work with a bunch of DevOps and TechOps people and the vast majority would rather be using windows, but because of the lack of features with the command box they are stuck using MAC's

Currently there appears no clean way to get the corresponding Windows process ID of a running WSL process. I can inspect the PIDs of running processes in Windows taskmanager or with the tasklist command from bash on WSL as in:

oeffner@grove:~$ cmd.exe /c tasklist

But that does not guarantee unambiguous identification PIDs if more processes have the same name.

It would be great if the PID of a WSL process was available as an additional column for Windows TaskManager and the tasklist command.

It would also be great if it were possible under WSL to get the corresponding Windows PID of a running WSL process.

Currently there appears no clean way to get the corresponding Windows process ID of a running WSL process. I can inspect the PIDs of running processes in Windows taskmanager or with the tasklist command from bash on WSL as in:

oeffner@grove:~$ cmd.exe /c tasklist

But that does not guarantee unambiguous identification PIDs if more processes have the same name.

It would be great if the PID of a WSL process was available as an additional column for Windows TaskManager and the tasklist command.

It would also be great if it were possible under WSL to get the corresponding Windows PID…

In the WSL you should be able to scroll up and see your previous sessions commands/output (much like you can with cmd). Currently you only get what you can see on the screen, forcing you remember to pipe everything to less.