3 ms·

With WSL2, is there any objective reason to write new Powershell scripts in 2024? I am genuinely curious because I barely have used Windows these days and had s

With WSL2, is there any objective reason to write new Powershell scripts in 2024? I am genuinely curious because I barely have used Windows these days and had some brief experience with WSL2.

orthoxerox 2y ago
Bash has no access to Windows internals. Some parts of Hyper-V you can configure only through pwsh, there's simply no GUI there to do it.
sterlind 2y ago
PowerShell lets you script Windows itself. You can configure network interfaces, set group policy settings, change registry keys, install programs, gather diagnostics, etc. etc. Linux has systemctl, Windows has Start-Service. Linux has kill, Windows has Stop-Process. Linux has ip, Windows has Set-NetworkInterface. WSL2 is just a VM - one with a ton of slick host integrations, but a VM nonetheless. Its power to do anything to Windows itself is very limited. It's also not installed by default. Disclaimer: work for MS, not on PowerShell or WSL.
7bit 2y ago
If you love awk and sed, no. If you rather work with objects, yes, absolutely.
chem83 2y ago
Yes, there is. If you write bash to execute on WSL2, you’re just orchestrating the Linux VM (that runs on Hyper-V and is cleverly integrated into Windows and makes you feel like you have a native bash shell). If you want to automate Windows using bash, you need some runtime that translate all Linux-like calls to the Windows COM interface.
jasomill 2y ago
In addition to the reasons already stated, WSL2 is a heavy dependency. Compared to PowerShell: 1. Typical WSL2 distros require far more disk space. 2. RAM used by WSL2 may not be immediately freed when your script exits. 3. WSL2 distros don't auto-update, so telling someone to install, e.g., Ubuntu via the Microsoft Store is insufficient to ensure a well-maintained WSL2 instance. 4. WSL2 requires enabling Windows hypervisor support, which can be difficult (KVM) or impossible (non-bare metal EC2 instances) in virtualized Windows instances. While (1) is probably not a big deal and (2) and (3) have reasonable workarounds, (4), where relevant, tends to be a showstopper.

With WSL2, is there any objective reason to write new Powershell scripts in 2024? I am genuinely curious because I barely have used Windows these days and had some brief experience with WSL2.

orthoxerox 2y ago

Bash has no access to Windows internals. Some parts of Hyper-V you can configure only through pwsh, there's simply no GUI there to do it.

sterlind 2y ago

PowerShell lets you script Windows itself. You can configure network interfaces, set group policy settings, change registry keys, install programs, gather diagnostics, etc. etc. Linux has systemctl, Windows has Start-Service. Linux has kill, Windows has Stop-Process. Linux has ip, Windows has Set-NetworkInterface. WSL2 is just a VM - one with a ton of slick host integrations, but a VM nonetheless. Its power to do anything to Windows itself is very limited. It's also not installed by default. Disclaimer: work for MS, not on PowerShell or WSL.

7bit 2y ago

If you love awk and sed, no. If you rather work with objects, yes, absolutely.

chem83 2y ago

Yes, there is. If you write bash to execute on WSL2, you’re just orchestrating the Linux VM (that runs on Hyper-V and is cleverly integrated into Windows and makes you feel like you have a native bash shell). If you want to automate Windows using bash, you need some runtime that translate all Linux-like calls to the Windows COM interface.

jasomill 2y ago

In addition to the reasons already stated, WSL2 is a heavy dependency. Compared to PowerShell: 1. Typical WSL2 distros require far more disk space. 2. RAM used by WSL2 may not be immediately freed when your script exits. 3. WSL2 distros don't auto-update, so telling someone to install, e.g., Ubuntu via the Microsoft Store is insufficient to ensure a well-maintained WSL2 instance. 4. WSL2 requires enabling Windows hypervisor support, which can be difficult (KVM) or impossible (non-bare metal EC2 instances) in virtualized Windows instances. While (1) is probably not a big deal and (2) and (3) have reasonable workarounds, (4), where relevant, tends to be a showstopper.