Also the terrible terrible idea of using common unix shell command names as aliases for PowerShell commands that are similar but don't quite work the same way and take entirely different parameters.
...and that time period where Invoke-WebRequest used IE for parsing by default.
But other than those flaws I agree that it is really great.
> using common unix shell command names as aliases for PowerShell commands that are similar but don't quite work the same way
On any Linux/Unix, when `ls` is called, PS runs the native `ls` and not `Get-ChildItem`. These aliases only exist on Windows, where unless one is explicitly running a Unix-ish shell (WSL, Cygwin, MinGW, MSYS2, etc), PS will use these aliases. Plus, `ls`, `mv`, `cp`, and `rm` never really existed on Windows; the equivalent cmd binaries were `dir`, `move`, `copy`/`robocopy`, `del`.
Finally, this is a fairly tired argument against PowerShell...
It may be a 'tired' argument but a valid one. For me I keep using 'dosisms' in powershell. But they do not work because those commands are actually something different and you need the params for those items. One that gets me every time is is the 'dir /s' command which does not work in powershell because you should use -recurse which is the command for Get-ChildItem which is what it is really calling.
I think most people have this issue when jumping between shells. Each one is has its own way of working. But adding aliases, I can see why they did it. The problem is it was poorly done up front. Now they are kind of stuck with it and we get to deal with it. Also you may be expecting all of the sorting items out of dir/ls. But you do not get those. You get to pipe it and sort it in a secondary step. Which is fine. But can is a bit of a pain when you are used to something like 'dir /os' vs 'Get-ChildItem . | Sort-Object -Property Length'. It just takes some getting used to. But seems longer and more verbose to get the same effect.
It is nicer though when you want to act on those items though (which is where powershell shines) as everything is in an object and you can slice it down. But using it for 'shell' things like where is a file and what is the biggest in a folder it falls a bit flat and feels like the object model is in the way.
> where is a file and what is the biggest in a folder
You don't need to use the full commands and parameters. The commands have aliases, and parameters can be arbitrarily short (and case-insensitive) as long as they are unambiguous:
gci . | sort Length
gci . -r -inc <filename>
Furthermore, the PowerShell interpreter has an extremely powerful autocomplete, so these should be straightforward to look up.
If you are thinking I am a sarcastic detractor, I am not. I whole heartedly believe PowerShell is superior in every way that matters to more common POSIX shells.
I was unaware of the difference between Windows and Linux in this regard as I don't tend to use PowerShell on the few Linux systems I run. However, I maintain that it is still a mistake to alias them in Windows because anyone coming from a POSIX shell background will be misled.
> the equivalent cmd binaries were `dir`, `move`, `copy`/`robocopy`, `del`.
Nit: only robocopy is a binary in the list. The rest are built in to the command shell.
My sarcasm detector led me into thinking you were a sarcastic detractor (heh).
I get your point though; perhaps PowerShell should've stuck with the initialism aliases only (`gci`, `cpi`, `ri`, etc) and people wouldn't have nitpicked on this as though it was some powerful argument against PS.
Perhaps there could've been a banner saying `hey, this is Windows, use `gci` instead of `ls` with these xyz options`.
...and that time period where Invoke-WebRequest used IE for parsing by default.
But other than those flaws I agree that it is really great.