JeffreySnover

Those youngings probably don't remember what the Germans and Japanese did in the 40's either.

Or the good old day's when Ultrix ran like a racehorse on 4MB of ram (it did BTW!).

We don't do our credibility any favor when we live in the past and don't update our worldview based upon current facts.

Jeffrey Snover [MSFT]

That's not quite right. We have always focused on CUSTOMER success.

You are right that there is self interest in that (as Satya likes to say - it is hard to be successful if your customers aren't succeeding) but the PowerShell team has NEVER been confused about what the high order bit is.

Without going down the rabbit hole, I'll just point to the fact that our launch partners for PS Core were: - AWS - GCE - VMWARE

Jeffrey Snover [MSFT]

Process creation on Windows has always been significantly slower than Unix. That is why PowerShell is skewed towards "built-ins" vs launched applications. The ramification of that is slower startup times.

Interesting note - it is also the reason why PowerShell was able to adopt the more natural Verb-Noun model for cmd naming. In Unix, this would produce a huge # of files OR and you couldn't do "VERB NOUN" because then you would have to multiplex on the VERB. Unix's "NOUN VERB" is the result.

BTW - VMS DCL stepped on all these rakes which is why it is have VERB/NOUN and half NOUN/VERB. A complete mess.

Jeffrey Snover [MSFT]

If you have modules in your module path that don't declare their exports in the manifest, PowerShell has to inspect everything to find all the cmds. This is often what is going on when you have terrible startup times.

The second half of the quote is, “but sometimes it takes us a couple decades to get right”. :-)

Seriously though, have you checked out the search in O365? It is starting to get really good and wait till you see how this progresses in the next couple of years.

I think I’ll be proven right. :-)

We thought about that but the reality is that it does not work well for interactive experiences.

When you look at how admins get their job done, it starts in the interactive shell and then when the do things frequently, they put it into a simple script and when then need it to be more formal, they invest in making it production quality.

That is the flow that PowerShell was designed to support.

Jeffrey Snover [MSFT]

Syntax is like ice cream. Some people like vanilla. Others like chocolate.

Jeffrey Snover [MSFT]

PowerShell was designed to provide a very wide dynamic range of capabilities from interactive actions to simple ad hoc scripts to more formal programming. The goal was to have a single tool that admins and programmers could share to create and manage systems where they could pick how formal they needed to be to solve the problem at hand and can simply modify (vs replace) it as the solution need to be by more people or more production scenarios.

Jeffrey Snover [MSFT]

That is correct (prevent accidental script execution).

It is ABSOLUTELY NOT a security mechanism. That is why we we support this:

Set-ExecutionPolicy -ExecutionPolicy Bypass

I wanted to make it:

Set-ExecutionPolicy -ExecutionPolicy DoAnythingBecauseTExecutionPolicyIsNOTASecurityFeature

But the team didn't like that. (I should have overruled them on that one :-) ).

Jeffrey Snover [MSFT]

Yikes! - you shouldn't have to do Set-ExecutionPolicy every time you start a shell. Something is definitely wrong there.

Try doing a: Get-ExecutionPolicy -List to see what is setting it.

Then use -SCOPE on Set-ExecutionPolicy.

BTW - I hear you on the "only chmod the scripts you want" - that is a nice benefit of the Unix model.

Jeffrey Snover [MSFT]

That was the approach I took before inventing PowerShell. We didn't WANT to invent a shell - we were forced into it.

The problem was that Bash on Windows wasn't effective. At the heart of the matter is the difference in architecture between Unix and Windows. In Unix, most everything is a file so if you can modify files and restart processes, you can manage everything. In Windows, most everything is an API so tools that manipulate files don't do much for you.

Ergo - we needed an admin automation model which supported an API oriented architecture. Thus PowerShell.

NOTE - Bash on Windows today has a very different focus - it is not about managing Windows (which it still doesn't do) - it is about using OSS tools to develop OSS Software. It does a great job at that.

Jeffrey Snover [MSFT]

Here is how you do that:

$PSDefaultParameterValues["Out-File:Encoding"]="utf8"

Jeffrey Snover [MSFT]

That is right.

CMD.exe will be around to support script execution for a long long time.

Jeffrey Snover [MSFT]