Ed Wilson: Designing input for a script

Often when writing a script I follow a multistep process. The first thing to do, of course, is to come up with a bit of code that will perform the task that I am after. For example, if I want to obtain information about the BIOS on a computer, I will first figure out how to do this. In general everything in the script is “hard-coded” meaning that no variables are used. Here is an example:

Get-WmiObject –class win32_Bios –computername “localhost”

The next step is to put the value for the comptuername parameter into a variable, and then to move it into a function. To do this, I use the function keyword, and create a function. It looks like this:

Function Get-Bios ($computer)

{

  Get-WmiObject –class win32_Bios –computername $computer

}

The problem with this approach, is that if I know ahead of time I plan to put my code into a function, and to supply input from outside the script I can skip the first step and immediately write my code as a function. This will save a bit of time. In addition, if I know that I will be supplying more than one value, I may decide to change the name of the variable I use.

Once I have a variable to hold my input, I can then use whatever method I wish to assign a value to that variable. I can read a text file, I can query Active Directory, read a database, or do other things as well.

On Monday, we begin looking at designing input for a script over at the Script Center. It will be a cool series of articles.