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.
$_.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 data | Command naming | Platform | |
|---|---|---|---|
| PowerShell | Structured objects with real properties | Consistent Verb-Noun cmdlets (Get-Process, Stop-Service) | Windows built-in (5.1); PowerShell 7+ is cross-platform |
| Bash | Plain text streams | A large set of independently named Unix utilities, each with its own conventions | Linux/macOS native; available on Windows via WSL |
Cmdlets & Discovery — Get-Help, Get-Command
Every built-in PowerShell command is a cmdlet, consistently named Verb-Noun — Get-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.
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.
Hands-On Exercises
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.
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 solutionExplain 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 solutionChapter 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-HelpandGet-Command - Execution Policy blocks scripts by default;
RemoteSignedis the real recommended middle ground, notUnrestricted - Next chapter: Accessibility & Productivity Features