Re: Questionable reason to use powershell over bash. Part II
If it's not an ad bullshit, and you do mean parallelizing tasks, than it's awesome, however, it always has limitations, plus with parallel and some ad-hoc tools you can parallelize tasks inside your scripts with Bash as well.
Interesting. So Bash parallel execution allows the parallel parts of the scripts to run in the same environment, having read/write access to the same shell variables and synchronization mechanisms?
Again, depends on the goal you're trying to accomplish, tramp-mode (in GNU Emacs), GNU Parallel and/or GNU Screen come to my mind.
Hmm. In Powershell you can *script* multiple remote sessions. For example you can start by opening sessions to 50 hosts. Each host will be a "session". You can now execute commands on each individual session while the state within each session os carried over from command to command, and the result of the command (success code) marshalled back to the controlling console. Which means the the controlling script can exert control over each individual command executed on the remote hosts. This is not just piping a script over to be executed and having the final result reported back. This is about having fine-grained control over each command executed remotely - as part of a script.
And yes - if you execute commands in parallel using the Invoke-Command cmdlet (alias icm) you can control how many parallel executions you want.
9) PowerShell web access.
What the hell is that, what for?
For remote control using a well-known and firewall-friendly protocol (https).
Sounds very fishy and insecure to me.
Yeah well. Any time you open up your infrastructure to the outside world, it incurs a certain amount of risk. See it as an alternative to OpenSSH, only you can integrate with web based authentication mechanisms and minimize the different authentication mechanisms, assuming that you already has a web security regime in place. So, do you open open an SSH port or simply PWA on an existing administrative or intra-corporate website? PWA defaults to "no access" and must be configured to allow PWA to use PowerShell remoting to the internal hosts. The commands/modules available and access levels allowed can be configured as well.
10) Superior security features, e.g. script signing, memory encryption..
"Memory encryption" sounds redundant, did you turn off ASLR?
Memory encrypting in PowerShell is used to ensure that sensitive data - such as passwords and private keys - are stored encrypted in memory. This has nothing to do with ASLR. ASLR is *not* encryption (where did you get that idea?).
Heartbleed demonstrated what can happen to passwords and privatekeys stored unencrypted in memory. When you read a password/private key through the Read-Host -AsSecureString cmdlet or similar, the password/private key is read and encrypted character-by-character and is *never* stored in cleartext in memory. The encryption is based on the data-protection API (DPAPI) ensuring that not even an administrator using a tool to scan the memory will be able to decrypt the password. There are lots of ways passwords in memory can bleed out. Heartbleed demonstrated one (nasty) way. Other channels are backups, swap files, memory dumps etc.
What precludes you from signing or encrypting a Bash script? You can also automate it by writing an easy bash function to check for a signature and execute a script, you can package every script or a number of them inside the Debian/RedHat or other package container with signatures to install it system-wide.
In PowerShell this is built-in security, and the default level is quite restrictive. And it can be controlled through group policies, making it trivial to enforce policies about e.g. script signing across an entire organization. Sure you can build *something* with bash, but how do you *enforce* it?
How do you sign a bash script, btw?
Correct me if I am wrong, but I had the impression that Debian/RedHat package container signatures were only check when *installing* the package. PowerShell script signing is used to ensure that scripts executing on a computer has been approved by some authority and has not been tampered with.
Furthermore, the script execution policies can block scripts obtained through browsers/mail clients/instant messengers etc. or e.g. scripts copied from a non-intranet zone. Files obtained through such channels are "tainted" with the origin, and powershell can be set to disallow execution of such scripts. This is a level of protection against phishing.
11) Do that in bash?
Do what again, an explanation is required, if you don't mean quantum theory.
I think he was referring to using a browser to connect to a command prompt and typing commands/running scripts with intellisense support - right in the browser.
12) Strongly typed stripting, extensive data types,
Why not scripting in C then?
Because C is not script friendly. C is not type-safe. C's scope rules interferes with REPLs.
"e.g first class xml support and regex support right in the shell."
What kind of regex is there, BTW? Is it as good and efficient as in grep, sed, awk or perl?
Yes. It is even better. While it is the "perl" variant it even allows some nice tricks to support e.g. parenthesis balancing (matching only properly balanced open-close parenthesis). PowerShell/.NET regexes are is *very* efficient. Actually the .NET regex engine supports compiling regex'es all the way to machine code.
No, it won't. Someone wrote that by default PS tries to read the data in memory, unless you use some non obvious and ugly syntax to do ti the right way.
I assume you are referring to how PowerShell process pipelines of objects? PowerShell actually *does* process objects in a progressive manner - "pulling" each result object through the pipeline one at a time. So if that was what you were referring to, you are wrong (although *some* cmdlets like e.g. sort *will* collect all objects before starting to produce output).
14) Instrumentation, extensive tracing, transcript and *source level* debugging of scripts.
Of course, it needs a lot of debugging thanks to its complexity.
If you develop scripts for any type of automation, you will appreciate debugging capabilities. This sounds rather like a case of sour grapes.
The main thing is though, how PS compares with Bash and other shells in usability, ease and power as shell, an envelop between utilities and processes? That is the real question.
To each their own. Bash robust and well established. But it is not without quirks. To someone well versed in Bash, the concepts of PowerShell can be daunting. You will be challenged on "wisdom" you simply accepted as facts before. In my experience, the hardest part for "bashers" to get about PowerShell is how it was made for objects and APIs instead of text files.