That's what happens I guess when the people designing it haven't actually used a CLI day to day much, because, well, they're using Windows.
That's what happens I guess when the people designing it haven't actually used a CLI day to day much, because, well, they're using Windows.
The short terse commands and the really awkward, confusing, mistake prone syntax of sh or bash really reels their ugly head in scripts.
Interactive shell? No problem. But that's the beauty of PowerShell: verbosity and correctness in scripts, where the IDE quickly expands those long commands, and short aliases for interactive use.
Seems like the real solution is separating scripts from interactive use.
When used in an interactive shell short commands save time and effort. And it is easy to learn and remember them because in everyday work you need only about 10 commands. For some some commands which I use a lot I have one-two letter aliases to type even less e. g. i=fgrep.
It makes shell scripts less readable for someone who come from windows and and don't know even common shell commands, but for someone who use shell at least from time to time it should be easy to read.
Simple. All these commands work with providers, of which a file system is just one. Other providers include Windows Registry, environment variables, certificate stores, functions and variables in PowerShell runtime. More providers can also be created and plugged into the system. PowerShell Providers are essentially Window's FUSE. See [0] for details.
So, for instance, you can do `Get-ChildItem HKCU:` to list entries under HKEY_CURRENT_USER in the Registry, the same way `Get-ChildItem C:/` will list you top-level items on the C: drive. Worth observing: while the console output for these two commands is similar, the results are in fact different objects underneath (Microsoft.Win32.RegistryKey vs. System.IO.FileInfo).
In short, these commands are an abstraction over file-system-like things. Whether or not that was a good idea is a different question.
--
[0] - https://docs.microsoft.com/en-us/powershell/module/microsoft...
The "*" can even be in the middle. I open VS solution files all the time from Powershell. Since there are often many other files and folders with similar names alongside them I just type ".\*.sln" and hit tab.
The long names are the official readable names for scripting. It can and does have short aliases like "rm" that you would use in interactive mode.
> And what's with all of the capital letters?
PowerShell is case-insensitive. The capital letters are for readability.
But the biggest thing I'm happy about WRT Powershell is that it's consistent (and pretty well documented). At least it makes sense. Batch scripting really didn't.