Allthough I'm a C# developer and therefore have to use Windows at work, I did run Gentoo and Mint/Ubuntu at home for some years. Once I decided to move my personal stuff to Windows as well, I was running a lots of things I was missing, through Cygwin. I also tried MINGW and even Linux on Windows using VMWare's Unity mode.
In the end I settled for Cygwin back then. It wasn't perfect, but for me, it was the closest I could get to my old environment.
That was until WSL came along. Since then, I switched everything to WSL, changed all my scripts (running fish shell), tinkered with the config and with a little Cygwin-Portable-Trick I even have a "wsudo" command available to run stuff in an admin context from the command line. Stuff like "wsudo nano /etc/hosts" now works like a charm (compared to "sudo nano /etc/hosts" which would open the WSL's hosts file).
There are some things to consider, like "~" is not really "C:\Users<USER>". But using symbolic links is a good way of working around these problems without it feeling like a workaround. I ended up with the following for example:
~ = WSL Home
~/~ = Windows Home
~/Desktop = Windows Desktop
~/~/Desktop = also Windows Desktop
~/.ssh = symlink to C:\Users<USER>\.ssh
You need to keep in mind that your WSL has its root (/) located in your users "AppData" somewhere. This location is not easily accessible and has some special permissions etc set. This is the reason why I symlinked the folders into that location instead of the other way around. Altnernatively there is an option to tell WSL to use "C:\Users<USER>" as "~" but it's more of a hack and not officially supported by Microsoft.
There are some other settings to be set in /etc/wsl.conf for example if you want to be able to use ".ssh" from Windows Home symlinked to "~/.ssh" because of how permissions are set when WSL mounts stuff.
I kept documenting my transition from Cygwin to WSL in a blog post which I have to finalize, but if youre interested I'll post a link once ready.
I was planning on writing a script this morning get me straight into WSL as opposed to opening CMD or PowerShell and then running a command from there.
Thank you for the advice, and I'd love to see that blog post when it's ready!
Some more things I thought of which wouldn't be mentioned in the blog post but are also related to the transition:
WSL is not perfect, when it comes to interacting with hardware for example, you'll mostly have to rely on windows executables.
Rooting Android phones for example, you can't do it with adb from within WSL because it doesn't have access to the hardware at that level.
You can however use adb.exe in your commands instead and it works fine. Another example, disk partitioning, perfectly fine using "wsudo diskpart" and is completely interactive, but there is no other way like "mkfs.nfts /dev/sda1" to mess with your disks.
Another case I encountered recently is traceroute. WSL's implementation doesn't work as Windows doesn't allow access to the sockets that easily. As far as I can tell, Microsoft faces a hard decision to change a long running practice on socket permissions or implement an ugly workaround for WSL exclusively. But as in the other cases, if you don't explictily need the linux implementation of the command you can simply use tracert.exe instead.
As mentioned above I run the fish shell, nowadays I run it in WSLtty. I used to use fish for years on Gentoo.
I like the autocompletion features as well as its speed and combined with oh-my-fish's budspencer theme its amazingly powerful. The syntax is not hard to learn and version 3.0 is on its way which will fix some current flaws.
PowerShell on the other hand, I don't like. As a C# developer, I don't like that they didn't stick with the C# syntax. To me, it feels like a half implementation of C# and something, especially string concatenation. That's why I only use Powershell in scripts and even those only rarely, in cases where its just easier.
For example, a case we have at my current employer:
I constantly develop a Windows Desktop application which has to be deployed to 14 terminal servers.
As updates are required often I needed to find a way to do this automatically. I settled for an windows installer (MSI) because it allows updates to run silently and doesn't need people to close the application to do them. They simply restart the application and will be running the new version.
I could use a GPO but those are slow and you can't tell them to run immediately, with you observing the progress.
This is where Powershell comes in handy. A script using "PSSession" to run an "msiexec" command on all terminal servers.
The command points to the freshly brewed *.msi a GitLab runner just produced (due to my changes to master) and voila, all systems updated.
But apart from this and two other scenarios (WMI stuff), no Powershell for me.
For the other points mentioned in your post I didn't cover yet:
I use VS Code as well as Visual Studio every day.
VS Code combined with the rmate extension (rafaelmaiolla.remote-vscode) and a little script deployed to SSH hosts enables a powerfull command:
"rmate /etc/what/ever.log" executed in a SSH shell, opens a temporary copy of "ever.log" in your running VS Code instance on your local machine.
Saved changes get synced back to the remote host. If the file doesn't exist, it will be created.
You need to add an SSH port forward (-L ::) but then it even works for multiple remote shells at once.
Docker for Windows. I don't have a use case. Everything I could want dockerized, runs on linux anyway.
A virtual machine running Ubuntu Server 18.04.1 LTS using the offical Docker ppa and a portainer (portainer.io) container is everything I need.
I can easily connect to any of those containers using portainer or SSH, port forward whatever I want;
I can have an interactive command running from any container in one of my tmux panes constantly;
Or even run Birdie and other linux applications using X11-forwarding (this is of course also possible with the WSL instance).
Chocolatey I think was a great idea, which unfortunately didn't get the attention it deserved. I've tried it a couple of times over the years but since WSL came along, well, I have apt :)
I'll try to write it up ASAP but in the meantime you should have a look at WSLtty: github.com/mintty/wsltty.
Its an optimized version of MinTTY for WSL.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Allthough I'm a C# developer and therefore have to use Windows at work, I did run Gentoo and Mint/Ubuntu at home for some years. Once I decided to move my personal stuff to Windows as well, I was running a lots of things I was missing, through Cygwin. I also tried MINGW and even Linux on Windows using VMWare's Unity mode.
In the end I settled for Cygwin back then. It wasn't perfect, but for me, it was the closest I could get to my old environment.
That was until WSL came along. Since then, I switched everything to WSL, changed all my scripts (running fish shell), tinkered with the config and with a little Cygwin-Portable-Trick I even have a "wsudo" command available to run stuff in an admin context from the command line. Stuff like "wsudo nano /etc/hosts" now works like a charm (compared to "sudo nano /etc/hosts" which would open the WSL's hosts file).
There are some things to consider, like "~" is not really "C:\Users<USER>". But using symbolic links is a good way of working around these problems without it feeling like a workaround. I ended up with the following for example:
~ = WSL Home
~/~ = Windows Home
~/Desktop = Windows Desktop
~/~/Desktop = also Windows Desktop
~/.ssh = symlink to C:\Users<USER>\.ssh
You need to keep in mind that your WSL has its root (/) located in your users "AppData" somewhere. This location is not easily accessible and has some special permissions etc set. This is the reason why I symlinked the folders into that location instead of the other way around. Altnernatively there is an option to tell WSL to use "C:\Users<USER>" as "~" but it's more of a hack and not officially supported by Microsoft.
There are some other settings to be set in /etc/wsl.conf for example if you want to be able to use ".ssh" from Windows Home symlinked to "~/.ssh" because of how permissions are set when WSL mounts stuff.
I kept documenting my transition from Cygwin to WSL in a blog post which I have to finalize, but if youre interested I'll post a link once ready.
This is exactly what I was looking for!
I was planning on writing a script this morning get me straight into WSL as opposed to opening CMD or PowerShell and then running a command from there.
Thank you for the advice, and I'd love to see that blog post when it's ready!
Some more things I thought of which wouldn't be mentioned in the blog post but are also related to the transition:
WSL is not perfect, when it comes to interacting with hardware for example, you'll mostly have to rely on windows executables.
Rooting Android phones for example, you can't do it with adb from within WSL because it doesn't have access to the hardware at that level.
You can however use adb.exe in your commands instead and it works fine. Another example, disk partitioning, perfectly fine using "wsudo diskpart" and is completely interactive, but there is no other way like "mkfs.nfts /dev/sda1" to mess with your disks.
Another case I encountered recently is traceroute. WSL's implementation doesn't work as Windows doesn't allow access to the sockets that easily. As far as I can tell, Microsoft faces a hard decision to change a long running practice on socket permissions or implement an ugly workaround for WSL exclusively. But as in the other cases, if you don't explictily need the linux implementation of the command you can simply use tracert.exe instead.
As mentioned above I run the fish shell, nowadays I run it in WSLtty. I used to use fish for years on Gentoo.
I like the autocompletion features as well as its speed and combined with oh-my-fish's budspencer theme its amazingly powerful. The syntax is not hard to learn and version 3.0 is on its way which will fix some current flaws.
PowerShell on the other hand, I don't like. As a C# developer, I don't like that they didn't stick with the C# syntax. To me, it feels like a half implementation of C# and something, especially string concatenation. That's why I only use Powershell in scripts and even those only rarely, in cases where its just easier.
For example, a case we have at my current employer:
I constantly develop a Windows Desktop application which has to be deployed to 14 terminal servers.
As updates are required often I needed to find a way to do this automatically. I settled for an windows installer (MSI) because it allows updates to run silently and doesn't need people to close the application to do them. They simply restart the application and will be running the new version.
I could use a GPO but those are slow and you can't tell them to run immediately, with you observing the progress.
This is where Powershell comes in handy. A script using "PSSession" to run an "msiexec" command on all terminal servers.
The command points to the freshly brewed *.msi a GitLab runner just produced (due to my changes to master) and voila, all systems updated.
But apart from this and two other scenarios (WMI stuff), no Powershell for me.
For the other points mentioned in your post I didn't cover yet:
I use VS Code as well as Visual Studio every day.
VS Code combined with the rmate extension (rafaelmaiolla.remote-vscode) and a little script deployed to SSH hosts enables a powerfull command:
"rmate /etc/what/ever.log" executed in a SSH shell, opens a temporary copy of "ever.log" in your running VS Code instance on your local machine.
Saved changes get synced back to the remote host. If the file doesn't exist, it will be created.
You need to add an SSH port forward (-L ::) but then it even works for multiple remote shells at once.
Docker for Windows. I don't have a use case. Everything I could want dockerized, runs on linux anyway.
A virtual machine running Ubuntu Server 18.04.1 LTS using the offical Docker ppa and a portainer (portainer.io) container is everything I need.
I can easily connect to any of those containers using portainer or SSH, port forward whatever I want;
I can have an interactive command running from any container in one of my tmux panes constantly;
Or even run Birdie and other linux applications using X11-forwarding (this is of course also possible with the WSL instance).
Chocolatey I think was a great idea, which unfortunately didn't get the attention it deserved. I've tried it a couple of times over the years but since WSL came along, well, I have apt :)
I'll try to write it up ASAP but in the meantime you should have a look at WSLtty: github.com/mintty/wsltty.
Its an optimized version of MinTTY for WSL.