Modules, Aliases & the PowerShell Gallery

PowerShell Fundamentals

Chapter 11 · Modules, Aliases & the PowerShell Gallery

Chapter 1 opened this entire course on a promise: PowerShell aliases are just names you can define yourself, so the same trick that gives a real Linux terminal an ll shortcut is available here too. This chapter finally delivers on that — honestly, including the one place a plain alias genuinely can't do what a Bash alias can. Along the way, it covers the mechanism that lets any of this scale past what ships built-in: modules, and the public PowerShell Gallery they can be installed from.

What a Module Actually Is

A module is a packaged bundle of cmdlets, functions, and aliases — the same organizing unit a Python package or an npm package is for their own ecosystems, just for PowerShell commands specifically. Every built-in cmdlet used across this entire course already lives inside one:

Get-Module -ListAvailable | Select-Object Name, Version -First 5 # Chapter 3's own Get-Command search works against modules too Get-Command -Module Microsoft.PowerShell.Management

Most built-in modules auto-load the first time you call one of their commands — which is exactly why nothing in this course has needed an explicit Import-Module so far. When a module isn't in a discoverable path (or you want to be explicit), Import-Module <name> loads it into the current session directly.

The PowerShell Gallery: Installing Modules Someone Else Wrote

The PowerShell Gallery (PSGallery) is the public, central repository for community and Microsoft-published modules — PowerShell's own equivalent of PyPI or npm:

Find-Module -Name Az -Repository PSGallery Install-Module -Name Az -Scope CurrentUser Update-Module -Name Az

-Scope CurrentUser installs just for your own account, no administrator rights required — the sane default unless a module genuinely needs to be available to every user on the machine.

The central fact this chapter is built on
Chapter 3 trained you to discover anything already installed with Get-Command/Get-Help/Get-Member rather than memorizing it. The PowerShell Gallery is the exact same idea, one layer out — Find-Module discovers code you haven't installed yet, the same way Get-Command discovers cmdlets you haven't used yet. Neither one requires memorizing anything in advance; both are search tools built directly into the shell.

Set-Alias — And a Real Limit It Has

Set-Alias -Name ll -Value Get-ChildItem ll # runs exactly Get-ChildItem — no extra flags baked in
A PowerShell alias can't carry default arguments the way a Bash alias can
In Bash, alias ll='ls -la' bundles both the command and its flags into one name. PowerShell's Set-Alias only ever maps a name to a single command — it has no way to attach -Force or any other default parameter to that name. Set-Alias -Name ll -Value Get-ChildItem makes ll behave exactly like bare Get-ChildItem, with none of the "show hidden items too" behavior a Bash user would reasonably expect from a real ll.

The ll Payoff: A Function, Not Just an Alias

Getting genuine Bash-ll behavior — a short name with default flags baked in — needs Chapter 7's own function syntax instead, using @args (Chapter 7) to still accept any extra arguments a caller adds on:

function ll { Get-ChildItem -Force @args } ll # Get-ChildItem -Force — shows hidden items too, like Bash's ls -la ll -Filter "*.txt" # extra arguments still pass straight through via @args

This is the honest answer to Chapter 1's own question: PowerShell can absolutely give you an ll shortcut with real default behavior — it just isn't Set-Alias that does it. A short function is the actual tool.

Making It Permanent: $PROFILE

Both approaches above vanish the moment the current session closes (Chapter 7's own scoping rules apply here too) — unless they're saved into your profile, a .ps1 script PowerShell runs automatically every time a new session starts:

$PROFILE # the path to your own profile script — may not exist yet if (-not (Test-Path $PROFILE)) { New-Item -ItemType File -Path $PROFILE -Force } notepad $PROFILE # add the ll function here — now it's there every time you open PowerShell
A first practical habit
Anything you find yourself retyping at the start of every PowerShell session — a personal alias, a small function like ll, a default working directory — belongs in $PROFILE, not repeated by hand. It's the same "load a library of reusable functions" idea Chapter 7 introduced with dot-sourcing, just running automatically instead of by hand.

Hands-On Exercises

Exercise 1

Explain why Set-Alias -Name ll -Value Get-ChildItem does not reproduce Bash's alias ll='ls -la' behavior. What actual PowerShell mechanism is needed to get real default-flags behavior, and why does that mechanism work where a plain alias can't?

📄 View solution
Exercise 2

Explain the difference between an ll function defined interactively in your current session and one added to $PROFILE. Specifically, why does one disappear when the window closes while the other doesn't?

📄 View solution
Exercise 3

You want to install a module from the PowerShell Gallery, use one of its cmdlets, then confirm which module actually owns that cmdlet. Write the sequence of commands you'd use, referencing earlier chapters' own discovery tools where relevant.

📄 View solution

Chapter 11 Quick Reference

  • Module — a packaged bundle of cmdlets/functions/aliases; most built-in ones auto-load on first use
  • Get-Module -ListAvailable / Import-Module — see what's installed / load one explicitly
  • PowerShell Gallery (PSGallery) — the public module repository; Find-Module / Install-Module -Scope CurrentUser / Update-Module
  • Set-Alias — maps a name to a command only; it cannot bake in default parameters, unlike a Bash alias
  • Real ll-with-defaults behavior — needs a function (function ll { Get-ChildItem -Force @args }), not Set-Alias
  • $PROFILE — your personal startup script; anything defined there persists across every future session
  • Next chapter: Capstone — Automating a Real Admin Task