{"id":1431,"date":"2009-05-21T04:00:27","date_gmt":"2009-05-21T12:00:27","guid":{"rendered":"http:\/\/www.sapien.com\/blog\/2009\/05\/21\/good-better-best\/"},"modified":"2009-05-21T04:00:27","modified_gmt":"2009-05-21T12:00:27","slug":"good-better-best","status":"publish","type":"post","link":"https:\/\/dev.sapien.com\/blog\/2009\/05\/21\/good-better-best\/","title":{"rendered":"Good, Better, Best"},"content":{"rendered":"

I’m very happy to see more and more people getting their hands dirty with Windows PowerShell.  A common challenge I see across different support forums is getting information from one part of a script to another. Very often the user has created a function and is attempting to use its output elsewhere in their script. Often I can tell the scripter is coming from a VBScript background or at least thinking that way. There’s nothing necessarily wrong with writing a PowerShell script in a VBScript style, but these scripts are missing out. Let me walk you through several iterations of a function to demonstrate.<\/p>\n

Here’s a variation on a function I saw posted recently.<\/p>\n

\n
\n
Function Get-Simple {<\/pre>\n
  <\/pre>\n
  $name=Read-Host \"Enter a name\"<\/span><\/pre>\n
  $password=Read-Host \"Enter a password\"<\/span> -asSecureString<\/pre>\n
  $size=Read-Host \"Enter a size\"<\/span><\/pre>\n
  $server=Read-Host \"Enter a server name\"<\/span><\/pre>\n
 <\/pre>\n
}<\/pre>\n<\/div>\n<\/div>\n
In VBScript this would probably be a subroutine and is an acceptable way to modularize a repeatable block of code. However the first problem is one of scope.  <\/p>\n
\n
\n
#this fails because the variables don't survive the scope<\/span><\/pre>\n
Get-Simple<\/pre>\n
Write-Host \"Creating $name on $server\"<\/span> -foregroundcolor CYAN<\/pre>\n<\/div>\n<\/div>\n
The variables in the Get-Simple function only exist for the function scope. Once the function ends, the scope evaporates and so do all of the variables. Normally the best practice is to not access out of scope variables and to define any variable in a given scope before you use it. However if you know what you’re doing and plan carefully you can access out of scope variables. Here’s a revised version of the Get-Simple function.<\/p>\n
\n
\n
Function Get-Simple2 {<\/pre>\n
  #assign variables to the parent scope<\/span><\/pre>\n
  #not a best practice but legal<\/span><\/pre>\n
  $script<\/span>:name=Read-Host \"Enter a name\"<\/span><\/pre>\n
  $script<\/span>:password=Read-Host \"Enter a password\"<\/span> -asSecureString<\/pre>\n
  $script<\/span>:size=Read-Host \"Enter a size\"<\/span><\/pre>\n
  $script<\/span>:server=Read-Host \"Enter a server name\"<\/span><\/pre>\n
}<\/pre>\n<\/div>\n<\/div>\n
Now this function is a little more usable in my PowerShell script, but there’s still a potential issue.<\/p>\n
\n
\n
#this now works, but the function is limited<\/span><\/pre>\n
Get-Simple2<\/pre>\n
Write-Host \"Creating $name on $server\"<\/span> -foregroundcolor CYAN<\/pre>\n
#look what kind of value $i provide based on $size from the function<\/span><\/pre>\n
$i=$size*4<\/pre>\n
$i<\/pre>\n<\/div>\n<\/div>\n
If you run this code and entered a number like 5 when prompted for a size, PowerShell will set$i to a value of 5555 because it will treat 5 as a string. Read-Host returns strings and this trips many PowerShell beginners. The solution is to cast<\/em> variables to the correct type. I’ll show you an example in a moment.<\/p>\n
Again, there’s nothing necessarily wrong<\/em> with this function, but it doesn’t take advantage of PowerShell’s object nature. Consider this improved version.<\/p>\n
\n
\n
Function Get-Better {<\/pre>\n
  #let's create an object<\/span><\/pre>\n
  $name=Read-Host \"Enter a name\"<\/span><\/pre>\n
  $password=Read-Host \"Enter a password\"<\/span> -asSecureString<\/pre>\n
  #cast $size as an integer<\/span><\/pre>\n
  [int]$size=Read-Host \"Enter a size\"<\/span><\/pre>\n
  $server=Read-Host \"Enter a server name\"<\/span><\/pre>\n
  <\/pre>\n
  #create an empty custom object<\/span><\/pre>\n
  $obj=New-Object PSObject<\/pre>\n
  <\/pre>\n
  #assign properties<\/span><\/pre>\n
  $obj | Add-Member -MemberType Noteproperty -name \"Name\"<\/span> -value $name<\/pre>\n
  $obj | Add-Member -MemberType Noteproperty -name \"Password\"<\/span> -value $password<\/pre>\n
  $obj | Add-Member -MemberType Noteproperty -name \"Size\"<\/span> -value $size<\/pre>\n
  $obj | Add-Member -MemberType Noteproperty -name \"Server\"<\/span> -value $server<\/pre>\n
 <\/pre>\n
  #write the object to the pipeline<\/span><\/pre>\n
  $obj<\/pre>\n
}<\/pre>\n<\/div>\n<\/div>\n
The function uses essentially the same Read-Host<\/strong> expressions. Notice that I’m casting $size as a [int]. Even though Read-Host<\/strong> will output a string, as long as I enter something that looks like a number PowerShell will attempt to convert it to the correct type. By the way, depending on your needs you might also have used types like [int64] or [double]. The main change to this function is that it will write an object to the pipeline. I create an empty generic object using New-Object<\/strong> and then pipe it to Add-Member<\/strong> to define properties. The property values come from the Read-Host<\/strong> commands. A function like this is much more PowerShell-like.<\/p>\n
\n
\n
$var=Get-Better<\/pre>\n
 <\/pre>\n
Write-Host \"Creating $($var.name) on $($var.server)\"<\/span> -foregroundcolor CYAN<\/pre>\n
#Now look what kind of value we get from $i<\/span><\/pre>\n
$i=$var.size*4<\/pre>\n
$i<\/pre>\n<\/div>\n<\/div>\n
PowerShell no longer has to rely on simple values. I have a rich object with properties of varying types that I can easily manipulate. I hope you can see how this is an improvement over the original function. But wait…there’s more.<\/p>\n
When I write a function or even a script, I want it to be as flexible and easy to use as possible. Here’s one more improvement.<\/p>\n
\n
\n
Function Get-Best {<\/pre>\n
 Param([string]$name=$(Read-Host \"Enter a name\"<\/span>),     <\/pre>\n
       [Security.SecureString]$password=$(Read-Host \"Enter a password\"<\/span> -asSecureString),<\/pre>\n
       [int]$size=1,<\/pre>\n
       [string]$server=$(Read-Host \"Enter a server name\"<\/span>)<\/pre>\n
       )<\/pre>\n
  <\/pre>\n
  #create an empty custom object<\/span><\/pre>\n
  $obj=New-Object PSObject<\/pre>\n
  <\/pre>\n
  #assign properties<\/span><\/pre>\n
  $obj | Add-Member -MemberType Noteproperty -name \"Name\"<\/span> -value $name<\/pre>\n
  $obj | Add-Member -MemberType Noteproperty -name \"Password\"<\/span> -value $password<\/pre>\n
  $obj | Add-Member -MemberType Noteproperty -name \"Size\"<\/span> -value $size<\/pre>\n
  $obj | Add-Member -MemberType Noteproperty -name \"Server\"<\/span> -value $server<\/pre>\n
 <\/pre>\n
  #write the object to the pipeline<\/span><\/pre>\n
  $obj<\/pre>\n
}<\/pre>\n<\/div>\n<\/div>\n
This function accepts parameters. I’ve cast each parameter to the appropriate type. This forces PowerShell to verify that the value is of the correct type. If not an exception will be raised and PowerShell will terminate the command. This is preferable to getting unexpected results from your function because an object is not the type you were expecting. Notice I’m also providing default values for each variable. In keeping with the original function I’ll prompt for a value if none is specified. The $size parameter has a default value of 1. If you run this code, the experience and results are essentially the same.<\/p>\n
\n
\n
$var=Get-Best<\/pre>\n
 <\/pre>\n
#Now look what kind of value we get from $i<\/span><\/pre>\n
Write-Host \"Creating $($var.name) on $($var.server)\"<\/span> -foregroundcolor CYAN<\/pre>\n
$i=$var.size*4<\/pre>\n
$i<\/pre>\n<\/div>\n<\/div>\n
However, if I already know what value I want to specify for a given parameter, all I need to do is specify it.<\/p>\n
\n
\n
$var=Get-Best -size 5 -server \"FILE01\"<\/span><\/pre>\n
Write-Host \"Creating $($var.name) on $($var.server) with a size of $($var.size)\"<\/span> -foregroundcolor CYAN<\/pre>\n
#returns Creating Jeff on FILE01 with a size of 5<\/pre>\n<\/div>\n<\/div>\n
This final version of my function has everything I need to fully take advantage of PowerShell. It writes an object to the pipeline that is easy to use and can be customized via input parameters, many with default values. <\/p>\n
I hope you found this “object” lesson helpful. PowerShell v2.0 takes us even further but I’ll save that discussion for another day.<\/p>\n<\/p>\n
\n
If you’d like to try out these functions, download a script file here.<\/a><\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
I’m very happy to see more and more people getting their hands dirty with Windows PowerShell.  A common challenge I see across different support forums is getting information from one part of a script to another. Very often the user has created a function and is attempting to use its output elsewhere in their script. Often I can tell the scripter is coming from a VBScript background or at least thinking that way. There’s nothing necessarily wrong with writing a PowerShell script in a VBScript style, but these scripts are missing out. Let me walk you through several iterations of a function to demonstrate.<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[283,25],"tags":[223,282,242,82,28,57],"class_list":["post-1431","post","type-post","status-publish","format-standard","hentry","category-howto","category-windows-powershell","tag-add-member","tag-functions","tag-new-object","tag-objects","tag-powershell","tag-scripting"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/posts\/1431","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/comments?post=1431"}],"version-history":[{"count":0,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/posts\/1431\/revisions"}],"wp:attachment":[{"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/media?parent=1431"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/categories?post=1431"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dev.sapien.com\/blog\/wp-json\/wp\/v2\/tags?post=1431"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}