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.
I am a C# programmer at heart, and I use powershell a good bit. I can honestly say I can never use powershell without my cheat sheets or my list of favorite commands (and especially the arguments to use).
I looked at this and kinda get it and think I could do some things with it. I don't think it's as powerful and can _definitely_ say it won't be capable of the same automations we use.
That said, the text parsing people do with bash makes me cringe. It's so repulsive and sketchy. Anything to get linux world off of bash would be a good thing.
Do you use pwsh as your daily driver? I find that its commands are as easily memorable as any other shell.
That being said You should enable these:
Set-PSReadLineKeyHandler -Key Tab -Function MenuComplete
Set-PSReadLineOption -PredictionSource History
MenuComplete will give you a menu of arguments that each command takes so you can easily see them when pressing tab for completions and prediction source will try to predict the commands you want based on your history.
Also make sure you're on latest version of PSReadLine (I had some problems with it not updating properly and had to do a manual `Install-Module PSReadLine -Force`) and try
you also get the normal intellisense autocompletions in the listview. And remember that if you have all the help files installed locally you can use F1 to view help for the current parameter/command.
I use pwsh as my daily driver, and the verbosity actually reduces my need for a cheatsheet.
What I'd love is for Powershell to _stop_ adding .\ to my tab completed files. Just quote it and leave it alone, unless it's an executable.
Once I got used to stuff parsing as objects, it's really hard to go back to everything-as-a-string in bash. I've gotten to writing a few personal scripts/modules.. processing stuff in JSON is just really nice.
Honesty, I believe this because of the maturity of powershell and not any inability in nushell. Having literally the number of commandlets and having entire .net framework available makes powershell have more options.
Additionally, pretty much every Windows Server feature is commandable with powershell. Some (much?)_ of the UI stuff in windows is just using powershell under the hood.
That said. I am _very much_ looking forward to using nushell when I use linux or wsl. And I wish your team great success. Linux needs it.
Yeah, we're probably never going to be able to compete with PowerShell's sheer volume of Windows integration points. Shelling out to pwsh is probably the best we can do in some situations.
Something I've been curious about - are there any plans to sink serious effort into massively expanding the stdlib? Powershell's syntax and object-orientation I could take or leave, but access to the entire .NET Framework is pretty hard to beat, and the same draw exists for xonsh. Nushell is neat but there just aren't enough builtins.
I don't think we're going to be able to compete with PowerShell's bajillions of developer-hours invested in deep Windows integration. But we are looking at revamping the Nu language to make it much more pleasant+powerful as a scripting language.
What kinds of features are you looking for in the stdlib?
It's less any specific missing features and more the confidence that I'll literally never run into a missing feature - the things you almost never need, until you do. E.g. upcasing a Turkish string, or printing a number that does the correct thing with `,` and `.` in the user's current locale. PowerShell's support for ACLs is also hugely helpful - being able to do the structured-data thing with the icacls command would go a long way.
No need for (a minimal set of) dotnet runtime. This means Nushell can possibly run on slightly resource constrained environment such as Raspberry Pi, of course you don't expect it to run well with 256MB of RAM though. Also, Nushell is battery packed. For example, say bye bye to your Oh-my-ZSH because the features you have with OMZ (like shell autocompletion, suggestion, theming and formatting) is built-in in Nushell. I have also tried to parse `zfs list` output in my Proxmox machine that I don't want to use `zfs list | less` that often.
That said, I hope Powershell Core can be packed with dotnet 7 native AOT mode [1] so we don't have to screw around with 100 different MSIL DLL files to run a single shell...
PowerShell is case-insensitive, you don't need to type caps for variable/function references if you don't want to. You'll still have hyphens, but in an interactive shell (as opposed to a script) there are many aliases you could use that avoid hyphens (or you can make your own).
It's more Unix-y. Smaller footprint, opens faster, short commands by default. Otherwise the PowerShell influence is vastly understated in project page and docs.
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.