Chapter 20: Improving your parameterized script
The introduction explains that parameters let people run a script without changing its contents.
After this chapter you will be able to
- Parameterized script interface. Explain that a parameterized script lets someone provide input through parameters rather than editing the script itself.
- Flexible script output. Explain why the script uses Select-Object instead of Format-Table: outputting objects lets someone choose how to display or export the results later.
- Advanced script directive placement. Explain where to put [CmdletBinding()] and what adding it does to the script.
- Mandatory ComputerName parameter. Explain how marking -ComputerName as mandatory replaces reliance on a hardcoded default with a prompt when the caller omits it.
- Parameter aliases and scope. Explain why the script keeps -ComputerName while adding -host as an alternative name, and state which parameter the alias affects.
- Drive type parameter validation. Explain why the script should accept drive types 2 and 3 but prevent other drive types, and identify ValidateSet() as the validation technique used for this parameter.
- Optional verbose progress output. Explain how Write-Verbose and [Cmdlet-Binding()] let someone run the script with or without progress messages, and how verbose output from commands inside the script is affected.
What it builds on
- Creating a parameterized script (chapter 19) · The parameterized script created in the previous chapter.
- Truncating parameter names (chapter 4) · PowerShell permits shortened parameter names when they identify the intended parameter.
- Other ways to write (chapter 17) · Earlier discussion of ways to produce output, including Write-Verbose.
- Using variables: Fun tricks with quotes (chapter 16) · Using variables within double-quoted strings.
Section by section
Introduction
The introduction explains that parameters let people run a script without changing its contents.
- Parameterized script interface: Explain that a parameterized script lets someone provide input through parameters rather than editing the script itself.
Why it matters: This distinction explains why a script can be shared with people who need to supply input but not edit its commands.
Key terms: parameterized script, parameters
20.1 Starting point
This section changes a parameterized script to output objects instead of a formatted table so its results can be used in different ways.
- Flexible script output: Explain why the script uses Select-Object instead of Format-Table: outputting objects lets someone choose how to display or export the results later.
Why it matters: Keeping the output as objects lets you decide later whether to display it as a table or save it as CSV.
Key terms: Select-Object, Format-Table, objects, preformatted output
20.2 Getting PowerShell to do the hard work
Adding [CmdletBinding()] in the required position turns the existing script into an advanced script without changing how it normally runs.
- Advanced script directive placement: Explain where to put [CmdletBinding()] and what adding it does to the script.
Why it matters: This one-line change prepares an existing script for additional PowerShell features.
Key terms: [CmdletBinding()], advanced script, comment-based help
20.3 Making parameters mandatory
The section shows how to require a script parameter and explains how parameter declarations affect the prompt users see.
- Mandatory ComputerName parameter: Explain how marking -ComputerName as mandatory replaces reliance on a hardcoded default with a prompt when the caller omits it.
Why it matters: The script can request a missing computer name instead of silently using a fixed one. - Param block declarations: Describe how the Param() block groups parameters, decorators, and data types, and explain which parameter the Mandatory attribute affects in this example.
Why it matters: Reading each declaration as a unit helps you see which parameter an attribute modifies. - Meaningful mandatory prompts: Explain how a descriptive parameter name and an optional help message can make the prompt for a missing mandatory parameter clearer.
Why it matters: A clear prompt helps someone running the script understand what value to enter.
Key terms: -ComputerName, [Parameter(Mandatory=$True)], mandatory parameter, Param() block, decorators, Mandatory attribute, [string], [int], parameter name, HelpMessage
20.4 Adding parameter aliases
This section shows how to give a script parameter an alternative name while keeping its conventional PowerShell name.
- Parameter aliases and scope: Explain why the script keeps -ComputerName while adding -host as an alternative name, and state which parameter the alias affects.
Why it matters: Aliases make a script easier to call without giving up a familiar PowerShell parameter name. - Parameter name abbreviation: Distinguish typing a recognizable part of a parameter name from adding an alias.
Why it matters: This distinction helps explain why a short spelling may work even when no alias was added.
Key terms: -ComputerName, -host, parameter alias, decorator, parameter name, alias
20.5 Validating parameter input
The section explains why the script should restrict its drive-type parameter and identifies ValidateSet() as the validation technique to use.
- Drive type parameter validation: Explain why the script should accept drive types 2 and 3 but prevent other drive types, and identify ValidateSet() as the validation technique used for this parameter.
Why it matters: Validating the input helps keep the script’s results relevant to the disk measurements it reports.
Key terms: -drivetype, Win32_LogicalDisk, ValidateSet()
20.6 Adding the warm and fuzzies with verbose output
This section shows how a parameterized script can provide optional verbose progress messages and include variable values in those messages.
- Optional verbose progress output: Explain how Write-Verbose and [Cmdlet-Binding()] let someone run the script with or without progress messages, and how verbose output from commands inside the script is affected.
Why it matters: You can offer useful progress information without showing it on every run. - Variable values in messages: Describe how the script includes the computer name’s value in a verbose message.
Why it matters: A progress message is more useful when it identifies the computer involved.
Key terms: Write-Verbose, Write-Host, [Cmdlet-Binding()], -Verbose, $VerbosePreference, $computername, double quotation mark trick
20.7 Lab
20.8 Lab answer
Where this is used later
- Parameter block (chapter 22) · Recognizing parameter aliases helps when reading another script’s parameter block.
Concepts explained in this chapter
- param blockA param block is a PowerShell language construct that declares the parameters and default values of a script or function.
- aliasA parameter alias is an alternate name accepted by a command for one of its parameters.
- Write-VerboseWrite-Verbose is a PowerShell cmdlet that writes diagnostic or progress messages to the verbose stream.
- Select-ObjectSelect-Object is a PowerShell cmdlet that selects specified properties or creates customized objects from input objects.
- atomic typeA data type defines the kind of value represented and the operations applicable to that value.
- formattingThe formatting system is PowerShell's subsystem for converting objects into instructions for human-readable textual or onscreen output.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.