To Script, or Not To Script – That is the Question
Summary: Scripting Guy Ed Wilson talks about the design considerations that govern writing Windows PowerShell scripts.
Hey, Scripting Guy! I am trying to decide when it is best to write a script, and when not to write a script. Can you help me?
— BL
Hello BL, Microsoft Scripting Guy Ed Wilson here. It is interesting to me that this question came up recently, and I even wrote an answer for it. However, I received a number of questions via comments on the posting, and so I thought I would take an additional stab at an answer. (You might want to review the “Learn When to Write PowerShell Scripts and When Not to” blog posting as a starting point to today’s article.)
To script, or not to script – that is the question: whether it is nobler to construct a fine terse line of Windows PowerShell code or to draft an entire script and arm against a sea of troubles…
When it comes to the decision of writing a script or not, there are several questions I have to answer. Perhaps the most important question to answer is, “How easy is it to remember the command?” If the command that would have to be typed is cryptic, complicated, or otherwise difficult for me to remember, I will store the command in a script. Essentially that is what I am doing when I write a script is storing the command or commands in a script. When I store a command in a script, I usually do several things to clean up the command and to make it easier to understand. The first thing I do is replace aliases with actual commands. This is because I can never be certain if one alias will be present on some other system. This is true even if the alias is a canonical alias because all aliases can be deleted, modified, or repurposed through an interactively typed command in a Windows PowerShell console session, or through one of the six profiles that are available on a standard installation of Windows PowerShell 2.0.
After I have replaced all the aliases in the command, I also eliminate positional parameters. Therefore, the command that I store is the “long version” of the Windows PowerShell command. The next thing that I do is add comments to the top of the script. These comments include keywords, to help Windows Search locate the script for me when I try to search for it later. This step is vital because if the reason for storing the command in the script in the first place is that I cannot remember the command, I must add something to the script that I will be able to remember or else the script will be irretrievable. To enable the ability to search Windows PowerShell scripts I modify the Windows search settings and tell it to index the content of the scripts.
Suppose I have a command that I can easily remember, and one that can easily be typed, it might seem that this is a “no-brainer” that no script is required. However, suppose that script is used every day? In this case, repetition might make the difference and I might decide to store the command in a script anyway. The thing to consider here is that the newly created script should be easily accessible, memorable, and require less typing that the command itself. Therefore, a script name of This is my script that I have to run every day.ps1 might not be the best name for a daily command that lists the current processes (gps is the alias for Get-Process). In fact, if a command is a single cmdlet with few parameters, and it has a short alias such as gps, there is little likelihood that I will go to the trouble of writing a script to replace a three letter command.
One other consideration for writing a script instead of typing a command directly into the Windows PowerShell console, is when you are scheduling tasks. Some people like to use the Windows Task Scheduler to run a script, but one can also use the task scheduler to run a specific command also. The command seen here will launch Windows PowerShell and execute the Get-Process command on the local computer. The Windows PowerShell console window remains open so that the user can view the results of the command.
powershell -noexit -command &{get-process}
From a scheduled task perspective, it is better to write the results to a text file, instead of leaving a Windows PowerShell console window open. The command seen here will launch Windows PowerShell and execute the Get-Process command on the local computer. It then redirects the results of the Get-Process command to the myprocesses.txt file that will be created in the C:\fso folder. When the command is finished, the Windows PowerShell console closes.
powershell -command &{get-process} >C:\fso\myprocesses.txt
When I create a scheduled task to perform the above command, I can paste the command into the dialog box and tell it that I want the task to start a program. The task scheduler is smart enough to recognize that -command &{get-process} >C:\fso\myprocesses.txt is an argument, and that powershell is the command to run. This is seen in the following figure.
Upon creating the scheduled task it will appear in the Scheduled Task Library as seen in the following figure.
Another reason to consider writing a script is to give another person the ability to run a command. For example, with very little training I can have a user run a Windows PowerShell script. This script can make configuration changes on their local system, update configuration information in a central database, or send an email message to the help desk with the current desktop settings. If a user is expected to run a Windows PowerShell script, the best way to provide access to the script is through a custom shortcut that the user double-clicks. In addition, the script should not require any switches or parameters to be manually typed. In short, if a user must run the Windows PowerShell script, the script has to be self-contained, and self-launching. By default when a Windows PowerShell script is double-clicked it will open up in Notepad. However, by creating a shortcut that includes PowerShell.exe in the command line, and then passes the path to the Windows PowerShell script as an argument, then the user can be instructed to double-click the shortcut to launch the script. (This is the tactic I took when I created a utility script for the Scripting Wife that exposed a GUI and that she wanted to be able to directly launch the script. I talk about this technique in the Weekend Scripter article “Creating a GUI for a Windows PowerShell Script.”)
An excellent solution for user problems is to have the script email the troubleshooting information to the help desk and include the user name, the computer name, and the time that the script launched. You could use an input box to ask the user what they were doing when the problem occurred. In fact, I might write that script sometime; sounds like it would be fun.
BL, that is all there is to deciding between a command line and a script. Script design week will continue tomorrow when I will talk about how to work with functions.
I invite you to follow me on Twitter or Facebook. If you have any questions, send email to me at scripter@microsoft.com or post them on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
Light
Dark
0 comments