Chapter 19: You call this scripting?
The introduction contrasts what administrators can accomplish at the PowerShell command line with the reason to start using simple scripts: avoiding repeated typing.
After this chapter you will be able to
- Command-line work and simple scripts. Explain that the book’s work so far could be done at the PowerShell command line without writing scripts, and that a reason to start scripting is to avoid repeatedly typing the same commands.
- Scripts as ordered commands. Explain that a PowerShell script lists commands for the shell to execute in the specified order, much like a batch file or Bash script.
- Repeatable commands as scripts. Explain that a script lets you run a command repeatedly without retyping it, and describe how saving the working command as Get-DiskInventory.ps1 makes it a script.
- Changeable command inputs. Explain why a shared script should use variables for values that may change between runs, rather than requiring users to edit the command itself. Describe replacing a fixed parameter value with a variable while keeping an initial value for testing.
- Script parameter declaration. Explain how placing $computername in a Param() block makes it an input parameter and how its default value is used.
- Multiple parameters and defaults. Explain how the script can accept both a computer name and a drive-type filter, including what happens when either argument is omitted.
- Comment-based script help. Explain how special comments let a script provide help that resembles PowerShell’s own help files, and distinguish single-line from block comment syntax.
- Script and command pipelines. Distinguish the pipelines created by running commands individually from the pipeline used when those commands run in a script.
- Mixed object output formatting. Explain why the example script displays Process and TimeSpan objects differently, and state the section’s recommendation for script output.
- Scope hierarchy and lifetime. Describe global scope as the shell’s top-level scope and script scope as its child. Explain that a scope and its contents disappear when the associated shell or script stops running.
- Variable lookup and shadowing. Trace how PowerShell looks for a scoped element in the current scope and then its parents. Explain why a value defined in a script takes precedence over a same-named global value without changing that global value.
What it builds on
- Not scripting, but running commands (chapter 4) · The distinction between running commands and writing scripts.
- Getting familiar with Visual Studio Code (chapter 2) · Assumes basic familiarity with VS Code.
- Storing values in variables (chapter 16) · Variables can store values used by commands.
- Connecting one command to another: Less work for you (chapter 6) · A pipeline connects commands with a pipe symbol.
- Using positional parameters (chapter 4) · Using positional parameters in commands.
- Asking for help (chapter 3) · Using the help command to ask PowerShell for help.
- Working with the default formatting (chapter 11) · PowerShell’s default formatting of output objects.
- Introduction to variables (chapter 16) · The introduction to PowerShell variables.
Section by section
Introduction
The introduction contrasts what administrators can accomplish at the PowerShell command line with the reason to start using simple scripts: avoiding repeated typing.
- Command-line work and simple scripts: Explain that the book’s work so far could be done at the PowerShell command line without writing scripts, and that a reason to start scripting is to avoid repeatedly typing the same commands.
Why it matters: You can see why scripts may be useful without assuming you must first become a programmer.
Key terms: command-line interface, scripts, scripting
19.1 Not programming, more like batch files
This section presents a PowerShell script as an ordered list of commands and shows how to create one in VS Code.
- Scripts as ordered commands: Explain that a PowerShell script lists commands for the shell to execute in the specified order, much like a batch file or Bash script.
Why it matters: You can begin scripting with commands you already know how to run. - VS Code script workflow: Describe how to type commands in VS Code, run them with the Run button, and save them as a script.
Why it matters: This gives you a direct way to turn commands you run into a saved script.
Key terms: script, batch file, PowerShell scripts, VS Code, Run button, Save
19.2 Making commands repeatable
The section turns a reusable command into a saved PowerShell script and shows how to format and test it in VS Code.
- Repeatable commands as scripts: Explain that a script lets you run a command repeatedly without retyping it, and describe how saving the working command as Get-DiskInventory.ps1 makes it a script.
Why it matters: Saving a working command makes it easy to run again. - Readable multiline command formatting: Describe how the example is laid out across physical lines while remaining one command, and explain why it spells out cmdlet and parameter names.
Why it matters: Readable formatting helps you and others follow the saved command. - Incremental command testing: Describe how VS Code runs the whole command or a highlighted portion, and how testing progressively larger portions helps check the result.
Why it matters: Testing parts of a complex command lets you check their output before saving the whole thing.
Key terms: script, Get-DiskInventory.ps1, cmdlet-style verb-noun names, pipe character, parameter names, positional parameters, Run toolbar icon, F5, F8
19.3 Parameterizing commands
The section shows how to prepare a repeatable command for changing inputs by replacing fixed parameter values with variables, then explains how to split long commands across lines.
- Changeable command inputs: Explain why a shared script should use variables for values that may change between runs, rather than requiring users to edit the command itself. Describe replacing a fixed parameter value with a variable while keeping an initial value for testing.
Why it matters: This lets you make a command reusable without asking colleagues to modify its internals. - Long command line breaks: Describe how the examples continue a long command onto another physical line, including where a backtick must appear and where a pipeline can be broken without one.
Why it matters: Breaking a long pipeline at the right place keeps it readable without accidentally ending the command.
Key terms: -computername, $computername, -path, $filepath, localhost, backtick, pipe symbol, pipeline
19.4 Creating a parameterized script
This section shows how to turn hardcoded script values into parameters and run the script with positional or named arguments.
- Script parameter declaration: Explain how placing $computername in a Param() block makes it an input parameter and how its default value is used.
Why it matters: It lets someone reuse the script for another computer without editing it. - Script argument invocation: Describe how to supply a declared parameter positionally or by name when running the script, and why the example includes .\ before the script name.
Why it matters: These are the ways a caller can pass a value to the parameterized script. - Multiple parameters and defaults: Explain how the script can accept both a computer name and a drive-type filter, including what happens when either argument is omitted.
Why it matters: Separate parameters let callers vary either part of the disk-inventory request while retaining useful defaults.
Key terms: Param() block, input parameter, default value, $computername, named, positional, parameter name abbreviation, .\, -drivetype, -computername
19.5 Documenting your script
The section shows how to put PowerShell help in script comments and view it with the normal help command.
- Comment-based script help: Explain how special comments let a script provide help that resembles PowerShell’s own help files, and distinguish single-line from block comment syntax.
Why it matters: Readers of your script can get familiar PowerShell-style help without separate documentation. - Viewing script help: Describe how to request a script’s help from the console, including full help, and why the example includes a path.
Why it matters: A script’s users can discover its instructions through the same help command they already use.
Key terms: comment-based help, #, <# #>, .DESCRIPTION, .SYNOPSIS, help, -full, script path
19.6 One script, one pipeline
Explains why two commands can display differently when run in a script rather than individually, and why scripts should generally output one kind of object.
- Script and command pipelines: Distinguish the pipelines created by running commands individually from the pipeline used when those commands run in a script.
Why it matters: Putting commands in a script does not always produce the same display as running them one at a time. - Mixed object output formatting: Explain why the example script displays Process and TimeSpan objects differently, and state the section’s recommendation for script output.
Why it matters: This explains a surprising display change and gives you a practical way to avoid it.
Key terms: pipeline, script, pipeline output, Process objects, TimeSpan objects, formatting system, Out-Default, Out-Host
19.7 A quick look at scope
Explains how PowerShell scopes contain and resolve names, how script scope differs from global scope, and how to avoid relying on values outside a script.
- Scope hierarchy and lifetime: Describe global scope as the shell’s top-level scope and script scope as its child. Explain that a scope and its contents disappear when the associated shell or script stops running.
Why it matters: It explains why values created in a script do not simply become lasting shell values. - Variable lookup and shadowing: Trace how PowerShell looks for a scoped element in the current scope and then its parents. Explain why a value defined in a script takes precedence over a same-named global value without changing that global value.
Why it matters: It helps you predict which value a script will use when the same name appears in more than one scope. - Avoiding cross-scope reliance: Explain the section’s practical advice to assign a variable within a script before accessing it, rather than relying on a value in another scope; identify parameters in a Param() block as one way to supply that value.
Why it matters: It makes a script’s behavior less dependent on whatever happens to be defined in the shell that runs it.
Key terms: scope, global scope, script scope, current scope, parent scope, Param() block, parameters
19.8 Lab
Where this is used later
- “Now that I’ve read the book, where do I start?” (chapter 27) · Making commands repeatable through scripts
- Making parameters mandatory (chapter 20) · Builds on declared parameters when making them mandatory.
- (chapter intro) (chapter 20) · The parameterized script created in the previous chapter.
- Starting point (chapter 20) · The earlier version of the parameterized script produced a formatted table.
- Validating parameter input (chapter 20) · Builds on accepting parameter input when adding validation.
- Setting default parameter values (chapter 26) · The introductory idea that PowerShell variables have scope.
Concepts explained in this chapter
- bindingA variable is a named storage location that holds a value or collection of values and can be assigned a new value.
- positional parameterA positional parameter is a command or script parameter whose value can be supplied by its position without naming the parameter explicitly.
- scopeScope is the region of a script or session in which a variable or other name is accessible.
- Visual Studio CodeVisual Studio Code is a cross-platform source-code editor with an extensible extension system.
- commandA command is an executable instruction that a shell can invoke to perform an operation.
- default valueA default parameter value is an input automatically supplied to a command parameter when the caller does not provide one.
- param blockA param block is a PowerShell language construct that declares the parameters and default values of a script or function.
- PowerShell extensionThe PowerShell extension is a Visual Studio Code extension that adds PowerShell editing and development support.
- verb-noun naming formatVerb-noun naming is a command and script naming convention that combines an action verb with a descriptive noun.
← Chapter 18: Sessions: Remote control with less work
Chapter 20: Improving your parameterized script →
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.