PowerShell Basics for Windows Users

Windows 11 Fundamentals

Chapter 10 · PowerShell Basics for Windows Users

Chapter 1 named PowerShell as the third of this course's own three interfaces to the same underlying system state. Chapter 6 used it in passing for winget; Chapter 7 previewed ipconfig /flushdns. This chapter is PowerShell in its own right — how it actually works, and why it's a genuinely different kind of shell from anything Bash Scripting Fundamentals already covers, not just a Windows-flavored equivalent.

PowerShell vs. cmd — Two Very Different Shells Sharing a Terminal

cmd.exe is Windows's original command interpreter, tracing back to MS-DOS — still present, still occasionally necessary for a handful of legacy batch scripts, but with no real scripting language behind it. PowerShell is a genuine scripting environment with variables, functions, and real data types. A further wrinkle worth knowing: Windows PowerShell 5.1 ships built into Windows itself, while PowerShell 7+ is a separate, cross-platform, open-source install — Windows Terminal defaults to 5.1 unless 7 has been explicitly installed and set as the default profile, a genuinely common source of "which PowerShell am I even using" confusion.

The Object Pipeline — PowerShell's Real Defining Difference

This is the single most important contrast with Bash Scripting Fundamentals's own coverage. Bash pipes plain text between commands — each command receives a stream of characters and has to parse it back into meaningful data itself, often with tools like awk or sed doing that parsing. PowerShell pipes objects — structured data with real properties — so a command receiving piped input already has direct access to named fields, with no text-parsing step required at all.

# List every running process using more than 200MB of memory Get-Process | Where-Object { $_.WorkingSet -gt 200MB } # Sort those results by memory usage, descending Get-Process | Where-Object { $_.WorkingSet -gt 200MB } | Sort-Object WorkingSet -Descending

$_.WorkingSet refers directly to a named property on the process object flowing through the pipeline — no splitting a line of text on whitespace, no guessing which column holds the memory figure, the way an equivalent Bash pipeline built around ps and awk would need to.

Pipeline dataCommand namingPlatform
PowerShellStructured objects with real propertiesConsistent Verb-Noun cmdlets (Get-Process, Stop-Service)Windows built-in (5.1); PowerShell 7+ is cross-platform
BashPlain text streamsA large set of independently named Unix utilities, each with its own conventionsLinux/macOS native; available on Windows via WSL

Cmdlets & Discovery — Get-Help, Get-Command

Every built-in PowerShell command is a cmdlet, consistently named Verb-NounGet-Process, Stop-Service, Set-ExecutionPolicy. Get-Help <cmdlet> -Examples shows real usage examples for any cmdlet directly in the terminal; Get-Command *service* finds every cmdlet whose name contains a given word, a genuinely fast way to discover a command whose exact name isn't already known.

A First Script — and the Execution Policy Gotcha

A PowerShell script is simply a text file saved with a .ps1 extension. By default, though, Windows blocks scripts from running at all — a security measure called Execution Policy, distinct from anything covered so far in this course.

# A simple first script — free disk space on the C: drive, in GB Get-PSDrive C | Select-Object @{Name="FreeGB";Expression={[math]::Round($_.Free / 1GB, 2)}}
"Running scripts is disabled on this system"
A script downloaded from the internet and run directly will typically fail with this exact error — the default Execution Policy (Restricted) blocks all scripts, downloaded or otherwise. The fix, Set-ExecutionPolicy RemoteSigned, allows locally written scripts to run freely while still requiring downloaded scripts to be digitally signed — a real, deliberate middle ground, not something to bypass entirely with Unrestricted just to make an error go away.
Tab completion is a real discovery tool, not just a shortcut
Typing a partial cmdlet name and pressing Tab cycles through every matching cmdlet PowerShell knows about — genuinely useful for recalling a command's exact name or spelling without leaving the terminal to search for it.

Hands-On Exercises

Exercise 1

Explain why a PowerShell pipeline built around Get-Process | Where-Object doesn't need to parse text the way an equivalent Bash pipeline built around ps and awk would.

📄 View solution
Exercise 2

A user downloads a .ps1 script and double-clicks it, but nothing happens — running it from a terminal instead shows "running scripts is disabled on this system." Explain what's happening and the recommended fix, using this chapter's own warn-box.

📄 View solution
Exercise 3

Explain why "Windows PowerShell" and "PowerShell 7" being two genuinely different things, rather than just two version numbers of the same product, is worth knowing before troubleshooting a script that behaves differently on two machines.

📄 View solution

Chapter 10 Quick Reference

  • cmd.exe — legacy, no real scripting language; PowerShell — genuine scripting environment
  • Windows PowerShell 5.1 (built in) vs. PowerShell 7+ (separate, cross-platform install) — two genuinely different products
  • PowerShell's object pipeline vs. Bash's text pipeline is the single biggest structural difference between the two shells
  • Verb-Noun cmdlets, discovered via Get-Help and Get-Command
  • Execution Policy blocks scripts by default; RemoteSigned is the real recommended middle ground, not Unrestricted
  • Next chapter: Accessibility & Productivity Features