Automating the world one-liner at a time…
In my earlier blog, I mentioned that we had changed things since the previous CTP. Rather than leave everyone wondering whether they were doomed or not, I decided to have an early release of that portion of the release notes. Here they are:
Breaking Changes to Windows PowerShell 1.0
1. The value of the PowerShellVersion registry entry in HKLM\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine has been changed to 2.0.
2. Added new language keywords: Data, Cmdlet, and DynamicParam. Any commands called data, cmdlet or dynamicParam are interpreted as language keywords and result in parsing errors.
3. Changes in argument separator behavior. In Windows PowerShell 1.0, $a.method(,1) is interpreted as a call with an array of 1 element, but $a.method(1,,2) generates a parsing error. In Windows PowerShell V2, both formats generate parsing errors.
4. New cmdlets and variables have been added. These are listed below. These new elements might conflict with variables and functions in profiles and scripts.
Breaking Changes to Windows PowerShell V2 (CTP)
Jeffrey Snover [MSFT] Windows Management Partner Architect Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
PingBack from http://blog.sapien.com/index.php/2008/04/24/a-new-powershell-v2-ctp/
So let me get this straight. We have Param as a keyword, and [Parameter()] as an attrib declaration. That is going to trip people up, don't you think?
After tossing it around I just don't feel good about the attrib declaration stuff, the syntax is just whack. I guess Parameter is a function now?
Question from IRC: "<Jaykul> meaning we can actually do: Parameter(0,1,0,1) if we can figure out the order?"
Hey Jeffrey, I think you should like, explain *why* when you do some of these things :P
I mean, the Parameter() thing Hal mentioned seems more like the C# syntax, but it also seems more verbose and a little too similar.
And what's with this Invoke-Command thing -- should it just be called Invoke-Remote? I mean, other than having all the remoting stuff, does it basically invoke expressions?
> I think you should like, explain *why* when you do some of these things
I totally agree. That is one of the purposes of this blog - to give you the story behind the story. Some insight into what we were thinking when we made the decisions we made. To understand what motivates us so you can predict what we'll do next, what input we are looking for etc.
BTW - this is why I LOVE Bruce Payette's PowerShell In Action book. Bruce wrote a book that exactly 1 person in the world could have written. He explains not just WHAT PowerShell is but WHY it is the way it is.
We should definately get around to explaining both of those topics but here is the backstory on them. Both of these were the subject of a TON of discussion, debate, long meetings, coffee discussions etc. Sometimes that process clarifies the issues and a decisive decision is made that is pithily explained. Other times, you end up balancing a wide range of competing goals.
I'll give you the "oxygen is good" level answer to both these and give you a raincheck on the longer discussion (We are trying to get the CTP out and I've got a ton of work to do for MMS next week.)
Parameter : This construct aligns with our goal of providing a smooth glidepath between PowerShell and C# and affords us a nice extensible framework for adding easily adding addition semantics.
Invoke-command: Our usability studies have videos of people's heads exploding trying to understand Invoke-Expression. Invoke-Remote was considered but this works in the local runspace as well so that is inappropriate. It also have rather sophisticated semantics which are difficult to capture in a name but once you understand them, "invoke-command" is a resonable name.
Your head is going to spin (one way or the other but hopefully with delight) when you grok what Invoke-Command ACTUALLY does. I think you'll see that this is a good example of really good design that masks a (necessarily) very complex world.
Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
> Our usability studies have videos of people's heads exploding trying to understand Invoke-Expression.
Can we get a couple of these on YouTube?
Thanks for the explanations :)