Alias CMD command from WSL2 shell
Others more knowledgeable than me may know of better methods or be able to suggest improvements, but the easiest way I could think of to solve this was to use a Bash alias. I created an alias called lsd
(short for list devices or disks) that I can run without ever needing to leave the WSL shell, while it remains as fast as running the command in CMD itself.
From a WSL shell, navigate to your home folder:
cd ~
...and open it in Windows Explorer:
explorer.exe .
Open the .bashrc
file in your home folder with a plain text editor like Sublime Text, and add the following line to the bottom of it:
alias lsd="cmd.exe /c '*wmic diskdrive get Model,Manufacturer,Size,DeviceID,Status,InterfaceType'"
This creates an alias (another command, for all intents and purposes) called lsd
that runs an instance of CMD, which executes the wmic
command before terminating itself. Remember to replace my wmic
command above with the CMD command that you want to run.
Save the .bashrc
file, then load it into the shell by doing:
. ~/.bashrc
You can then simply run the alias like any other WSL command:
$ lsd
'\\wsl$\Ubuntu-18.04\home\user'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.
DeviceID InterfaceType Manufacturer Model Size Status
\\.\PHYSICALDRIVE0 IDE (Standard disk drives) WDC WD10PURX-64E5EY0 1000202273280 OK
\\.\PHYSICALDRIVE4 IDE (Standard disk drives) WDC WD30EZRZ-00GXCB0 3000590369280 OK
\\.\PHYSICALDRIVE2 IDE (Standard disk drives) CT250MX500SSD1 250056737280 OK
\\.\PHYSICALDRIVE6 USB (Standard disk drives) Seagate GoFlex Desk USB Device 3000582144000 OK
\\.\PHYSICALDRIVE1 IDE (Standard disk drives) KINGSTON SV200S3128G 128034708480 OK
\\.\PHYSICALDRIVE3 IDE (Standard disk drives) ST2000DM001-9YN164 2000396321280 OK
\\.\PHYSICALDRIVE5 USB (Standard disk drives) Kingston DataTraveler 3.0 USB Device 15471751680 OK
As seen above, my implementation of the alias does come with the non-fatal bug that the command returns a path error just before executing, but I haven't had the time to figure out how to solve this (follow-up question here). In any case, Windows corrects the issue itself, meaning it doesn't prevent the CMD command from executing as normal, and that the only real harm it does is make the output a little uglier than it should be.