| The top two of majkinetor's list are pretty easy to describe: PowerShell cmdlets (which is all built-in commands, most first party commands, some second and third party modules and wrappers and anything you can easily do in writing your own functions inside scripts) all share a single argument parser, rather than the usual command line application status quo in other shells where it is every app for itself in argument parsing and some programming languages are better than others at it and some libraries in languages are better than others. One thing the cmdlet argument parser is good at is that it does make it really easy for the cmdlet author to add aliases (alternate names) for arguments (which PowerShell calls Parameters to the cmdlet) right next to where you define your Parameters. As a comparison, this is equally easy in say Python's argparse where you can provide a list of possible argument names in addition to just a single name. (If you are rolling your own in, say, C it may feel a bit harder.) The other thing that PowerShell's shared argument parser supports is it always allows you to use the shortest non-ambiguous prefix to name an argument. (This is also something that Python's argparse does by default. Other languages/libraries it varies.) Which is basically that it always supports the "tab completion" automatically without actually having to type tab or "complete" the argument. For instance, the Remove-Item cmdlet often used by the alias `rm` doesn't seem to have any obvious aliases for its parameters, but `-r` works just fine like you would just about expect from other things named `rm` because there is no other parameter that starts R other than "-Recurse". It almost works equally well for Remove-Item's "-Force" parameter with the small hiccup that there is also a "-Filter" so you need `-fo`. Another thing these last couple things demonstrate is that PowerShell's shared argument parser is case-insensitive. (Python's argparse is not, which is where the shared similarities stop.) PowerShell parameters in documentation are almost always shown in PascalCase for readability but most day-to-day use I see tends to be all lower case just like you just have to do in bash (`rm -r -fo`), only in PowerShell it is an option if you are into brevity rather than the only language that these cmdlets understand/parse. Having a shared parser for all of this across so much of the shell (and easily used when writing your own functions which are treated as cmdlets just the same) means that you can count on it pretty much everywhere and you don't have to know anything about what language your command line tool was written nor worse what library in that language was used for argument parsing. (Python's argparse was only added to the standard library in Python 3.2! There's still tons of Python command line tools in the wild that don't use argparse at all and manually parse their args or use older libraries with fewer features from before the Python team declared a "winner" and added it to the standard library.) |
https://devblogs.microsoft.com/scripting/learn-about-using-p...
If you pipe objects around between cmdlets, PowerShell will auto-bind object properties to cmdlet parameters. Which feels like the magic of the Unix pipe text streams everywhere but lets you skip several text parsers (no grep/awk/sed intermediates perhaps) and feels like even more magic when it just works: `Get-Process -Filter something | Stop-Process`. The blog post gets into some of the details of how it works and that it isn't just magic and that in PowerShell you can even inspect with tools like Get-Help to discover how it is doing it and use that to your advantage to automate complex tasks with very simple command lines.