When we designed PowerShell we decided that we wanted to have Shell syntax and semantics because this is what was missing from the market and because it supports the ad hoc development practice that is so suited to the needs of administrators. We also observed that most shells ran out of power pretty quickly and people had to throw away their scripts and start from scratch with a more powerfull scripting language like Perl. Sadly, sometimes those environments ran out of power as well and people had to throw them away and start from scratch using a systems programming language like C++. We looked at those things and decided that PowerShell ALSO had to be a great scripting language and be decent systems programming language. This is the orgin of our quest to have the widest possible dynamic range.<\/p>\n
You don’t need to think about this very long to realize that we were going to run into some problems. Boy did we! That said, I was surprised at how many would disappear if you resisted the urge to say, “choose between Shell and Programming”. If you worked hard, got creative, and struggled with it, most of these apparent conflicts would give way to a great solution. That only worked so far and there were times when we had to choose and in general (but not always), we favored Shell over Programming. <\/p>\n
One of those areas was error generation. Shells are like the grandparents that you see a couple times a year – they love you and forgive almost anything.
Access a variable that doesn’t exist? We’re not going to complain.
Access a property on a variable that doesn’t exist? That’s OK.<\/p>\n
Now we’re not idiots so if you try to SET a property on a variable that doesn’t exist or call a method that doesn’t exist, we complain.<\/p>\n
These are great semantics for ad hoc programming but not for more rigourous programming and they can even burn you for ad hoc programming as well. If you misspell a name, things will run fine but you won’t get what you want. This is why we introduced STRICT MODE. In V1, we introduced a command SET-PSDEBUG -STRICT which puts PowerShell into strict mode where we complain if you access a variable that does not exist. <\/p>\n
That is really great but it has 2 problems. It is not all that strict and it sets the mode for the entire process. Roman Kuzmin brought this up this morning in a comment on the Select-Grid script. He pointed out that it made a call to SET-PSDEBUG -STRICT and warned that this was inappropriate for most environments because it causes your ad hoc scripts to start failing. Get it? So imagine have a sloppy ad hoc script that has these issues but works fine for your purposes. You then dot source Select-Grid and that script now starts throwing errors. Now imagine that it’s not just one script but dozens of scripts all throwing errors where they didn’t use to. A purist would say that those are broken scripts and you need to fix them all. A non-purist would say, “ish!!!” (an homage to my midwest friends).<\/p>\n
If you look at the name, you’ll see that we were actually pretty explicit about it. This is a technique that is useful for DEBUGGING your script. In V2, we introduce a new cmdlet that addresses many of the problems Set-StrictMode. This provides strict semantics in a way that does not affect the entire process AND it adds a number of new cases to check. We added these cases based upon the complaints we recieved and the errors we saw. That means 2 things:
1) Yes we listen to you. Please complain complain complain. We LIKE complaints. Every complaint is an opportunity for us to generate the worlds best product.
2) If we didn’t cover the case that keeps burning you – see bullet #1
We now consider it best practice to use this for scripts of any consequence. Certainly any script that you share with others or post on the internet should use this (to avoid embarrassing yourself [as I do all the time]).<\/p>\n
Without further ado, let me introduce you to fabulous new Set-StrictMode:<\/p>\n
NAME
Set-StrictMode<\/p>\n
SYNOPSIS
Establishes and enforces coding rules in expressions, scripts, and script blocks.<\/p>\n
SYNTAX
Set-StrictMode -Off -Version <Version> [<CommonParameters>]<\/p>\n
DETAILED DESCRIPTION
The Set-StrictMode cmdlet configures strict mode for the current scope and turns it on and off. When strict mode is
on, Windows PowerShell generates a terminating error when the content of an expression, script, or script block vi
olates basic best-practice coding rules. The strict mode is enforced only in the scope in which you set it.<\/p>\n
Set-StrictMode has three settings.<\/p>\n
Version 1:
Prohibits references to uninitialized variables (unless the variables are in strings).<\/p>\n
Version 2:
Prohibits references to uninitialized variables (including variables in strings).
Prohibits references to non-existent properties of an object.
Prohibits invalid function syntax (parentheses and commas).<\/p>\n
Latest:
Selects the latest (most strict) version setting.<\/p>\n
When Set-StrictMode is off, uninitialized variables (Version 1) are assumed to have a value of 0 or $null, dependin
g on type. References to non-existent properties return $null. and the results of invalid function syntax vary with
the error.<\/p>\n
Wider and wider the dynamic range of PowerShell grows!<\/p>\n
Jeffrey Snover [MSFT] When we designed PowerShell we decided that we wanted to have Shell syntax and semantics because this is what was missing from the market and because it supports the ad hoc development practice that is so suited to the needs of administrators. We also observed that most shells ran out of power pretty quickly and people had […]<\/p>\n","protected":false},"author":600,"featured_media":13641,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-6141","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-powershell"],"acf":[],"blog_post_summary":" When we designed PowerShell we decided that we wanted to have Shell syntax and semantics because this is what was missing from the market and because it supports the ad hoc development practice that is so suited to the needs of administrators. We also observed that most shells ran out of power pretty quickly and people had […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts\/6141","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/users\/600"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/comments?post=6141"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts\/6141\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/media\/13641"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/media?parent=6141"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/categories?post=6141"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/tags?post=6141"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at: http:\/\/blogs.msdn.com\/PowerShell<\/a>
Visit the Windows PowerShell ScriptCenter at: http:\/\/www.microsoft.com\/technet\/scriptcenter\/hubs\/msh.mspx<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"