Chapter 5: Working with providers

Introduction

Introduces providers as PowerShell’s way to present specialized data stores as drives for easier viewing and management.

• Provider access to data stores: Explain that a PowerShell provider gives access to a specialized data store and makes its data appear in a PowerShell drive for easier viewing and management.
  Why it matters: This idea helps make sense of why PowerShell shows more than filesystem data in drives.

Key terms: provider, specialized data stores, drive

5.1 What are providers?

This section explains how PowerShell providers adapt data stores into drive-like views, how PSDrives expose those views, and why provider capabilities matter.

• Provider as data adapter: Explain that a PSProvider adapts a data store, such as the filesystem or Windows Registry, so it looks like a disk drive.
  Why it matters: The drive-like view lets you approach more than just files through PowerShell.
• Provider capability differences: Explain that providers have different capabilities, which determine whether features such as -WhatIf and -Confirm, -Filter, or -Credential are supported.
  Why it matters: Checking a provider’s capabilities helps you avoid assuming that every parameter works with every data store.
• PSDrives and provider cmdlets: Distinguish a PSDrive from its provider: the PSDrive uses one provider to connect to data storage and make it accessible. Describe how cmdlets, commonly with Item in their noun, let you see and manipulate the exposed data.
  Why it matters: Keeping the provider and drive roles separate makes the chapter’s navigation and manipulation commands easier to understand.

Key terms: PowerShell provider, PSProvider, data storage, capabilities, ShouldProcess, Filter, Credentials, PSDrive, Item

5.2 Understanding how the filesystem is organized

This section explains how filesystem files and folders map to PowerShell’s generic item terminology, and why provider capabilities determine which operations work.

• Filesystem containers and endpoints: Describe how files and folders form a hierarchy: folders can contain files and other folders, while files are endpoints rather than containers.
  Why it matters: The container distinction helps you make sense of what can have child items.
• Items properties and children: Explain why PowerShell calls files and folders items, and distinguish Item, ItemProperty, and ChildItem in cmdlet names.
  Why it matters: These distinctions make provider cmdlet names meaningful across different data stores.
• Provider dependent operation support: Explain why a generic provider cmdlet or parameter may not work with every PSDrive, using a limitation described in the section.
  Why it matters: Checking what a provider supports prevents you from assuming every generic command works everywhere.

Key terms: folders, files, container, PSDrive, Item, ItemProperty, ChildItem, PSProvider, FileSystem provider, Environment PSProvider

5.3 Navigating the filesystem

This section explains how to change the current filesystem location, create a directory, and interpret drives on non-Windows systems.

• Changing the current location: Explain that Set-Location changes the shell’s current location to a container such as a folder, and that cd is an alias that accepts the desired path as a positional parameter.
  Why it matters: Changing location lets you work in the folder you intend.
• Creating a directory with New-Item: Explain why New-Item needs an item type when creating a directory, and distinguish that from the Windows PowerShell mkdir shortcut and its absence on non-Windows PowerShell Core.
  Why it matters: Specifying the item type avoids relying on a shortcut that differs across platforms.
• Non-Windows roots and PSDrives: Describe how macOS and Linux use a single root rather than drives for attached storage, while PowerShell still offers PSDrives for other providers.
  Why it matters: It prevents you from mistaking PowerShell’s PSDrives for physical storage drives on every platform.

Key terms: Set-Location, cd, current location, positional parameter, New-Item, -ItemType, directory, mkdir, root, PSDrives

5.4 Using wildcards and literal paths

This section explains how Item cmdlets interpret wildcard characters in paths and how to specify paths containing those characters literally.

• Wildcard path matching: Explain that the -Path parameter accepts wildcards by default: * matches zero or more characters, and ? matches one character.
  Why it matters: It helps you predict which items a path can match.
• Literal paths and parameter position: Describe when to use -LiteralPath instead of -Path and why its parameter name must be typed explicitly.
  Why it matters: It lets you address items whose names contain characters that would otherwise be interpreted as wildcards.

Key terms: -Path, wildcards, *, ?, -LiteralPath, positional

5.5 Working with other providers

Introduces the Environment provider as a cross-platform way to explore a non-filesystem PSDrive and item cmdlets.

• Environment provider as practice: Explain why the Environment provider is a useful place to explore providers and item cmdlets.
  Why it matters: It gives you a provider you can explore whether you use Windows, Linux, or macOS.

Key terms: PSDrive, item cmdlets, Environment

5.5.1 Windows Registry

This subsection applies PowerShell provider navigation to the Windows Registry by changing a Registry value and checking the result.

• Windows Registry provider workflow: Trace how to work with the Windows Registry as a provider: use the HKCU: drive to access HKEY_CURRENT_USER, navigate to the relevant location, change EnableAeroPeek to 0, and check that the change took effect.
  Why it matters: The same approach of navigating, changing a value, and checking it can help you work with other providers.

Key terms: Registry, HKEY_CURRENT_USER, HKCU: drive, EnableAeroPeek

5.6 Lab

5.7 Lab answers