Well, it is a good point, since nowadays PowerShell is also cross-platform, and seems to have more features than nushell does.
Though the true reason is: I haven't really found the time to. Changing a shell is really stressful since you have to unlearn / relearn lots of things from muscle memory, and PowerShell's huge deviance from the rest of the POSIX-y world doesn't help. At least in nushell `rm -rf` works, the same doesn't in PowerShell.
> PowerShell's huge deviance from the rest of the POSIX-y world doesn't help
In PowerShell (on Windows), `rm` is an alias to `Remove-Item`[0].
Therefore,
rm -r -fo <thing>
An extra dash, extra space, and extra letter isn't too bad by my books. Furthermore, in scripts, aliases are discouraged by PSScriptAnalyzer[1]; IDEs (PowerShell ISE, VS Code PowerShell extension) also support code completion, so:
why do they alias all this stuff. Remove Item is _not_ rm. It's so stupid. Like when they aliased wget and curl to some nonsense web request command and everybody complained that it didn't work.
I'll never use PowerShell. Just way too many bad decisions all over the place.
The alias only exists on Windows. Did you read the linked page?
The aliases in this table are Windows-specific. Some aliases aren't available on other platforms. This is to allow the native command to work in a PowerShell session. For example, ls isn't defined as a PowerShell alias on macOS or Linux so that the native command is run instead of Get-ChildItem.
`rm` was never an executable on a pure (aka non-MinGW, non-Cygwin, non-MSYS2, non-WSL) Windows console; the equivalents were/are `rmdir` and `del`. Microsoft's position is clear that PowerShell is meant to supersede these old commands, and hence the aliases, but again, only on Windows. I agree that Microsoft made some strange decisions to alias `curl`, etc on other platforms too in PS6, which were reversed for PS7.
These aliases are meant as stepping-stones for POSIX-first people to get their feet wet with the Windows command-line.
To make interactive usage easier? PowerShell essentially replaces the text-oriented environment provided by coreutils with an integrated object-oriented one.
In hindsight it probably would have been better if they just had a help message with something like "Oh you must be a *nix user, thanks for trying Powershell! You can do something similar with command xyz. Read that command's documentation -here- , and read a guide on the differences between posix and powershell -here-"
`dirs -v` would be `Get-Location -Stack`. Also in newish versions PowerShell `Set-Location` (aliased to `cd`) supports -/+ to move backwards/forwards in it's own history, so usually you don't even need to bother with `pushd`/`popd` unless you need a named stack.
Like all shells, PowerShell is split between being a scripting language and an interactive shell.
PowerShell leans a bit more towards being a scripting language than an interactive shell, so things are more verbose, as befits a shell script that needs to be read and updated later by a different programmer.
But yeah, lots of little trade offs like that permeate the language.
Less work than trying to add named stacks to bash. If it's so central to your workflow that you're willing to put up with the rest of bash just for it, adding a couple lines to your profile can't be that big of a deal.
Though the true reason is: I haven't really found the time to. Changing a shell is really stressful since you have to unlearn / relearn lots of things from muscle memory, and PowerShell's huge deviance from the rest of the POSIX-y world doesn't help. At least in nushell `rm -rf` works, the same doesn't in PowerShell.