Installing and Running PowerShell on Windows, Linux, and macOS

1. Installing PowerShell is not the same as installing a terminal

A terminal application gives you a window or session in which a shell can run. Installing PowerShell installs the pwsh executable, its runtime files, built-in modules, help infrastructure, and related components. You can then launch that executable from many terminals: Windows Terminal, a Linux terminal emulator, macOS Terminal, an SSH session, Visual Studio Code, or a CI runner.

This distinction is useful when troubleshooting. If a terminal opens but pwsh is “not recognized” or “command not found,” the problem may be that PowerShell is not installed or that its installation directory is not on PATH. Reinstalling the terminal application would not fix either problem.

2. Choose a supported release channel deliberately

PowerShell has supported production releases and preview releases. A Long Term Support (LTS) release is supported for a longer lifecycle and is a sensible default for a course or organization that values a stable baseline. Microsoft can also support a non-LTS stable release for a shorter period. A preview release exists so users can test upcoming behavior before general availability; it is not the course default and should not be introduced into production merely because its version number is higher.

The exact supported versions will change over time. For production automation, record the version family you support and keep it patched to the latest servicing update Microsoft supports for that family. “PowerShell 7” is too vague for a reproducible build if behavior depends on a feature added later.

For this course, examples assume PowerShell 7.6.x LTS unless explicitly marked otherwise. If you use a later supported release, most Chapter 01 examples should remain valid, but version-sensitive behavior in later chapters will be called out.

3. Windows installation choices

On Windows, Microsoft documents several installation methods because desktop, server, enterprise deployment, and side-loading needs differ. WinGet is the recommended installation mechanism for many Windows client scenarios. An MSI package is useful for server or centrally managed enterprise deployment. A ZIP package can support side-loading or multiple isolated versions when you intentionally do not want a machine-wide installer.

A typical WinGet invocation for the current PowerShell package is:

winget install --id Microsoft.PowerShell --source winget

The command above is an installation action, not part of the no-elevation verification lab later in this lesson. Depending on system policy and installation method, Windows may request elevation or user approval. On managed systems, follow your organization's software deployment policy.

After installation, modern PowerShell starts with pwsh or pwsh.exe. Windows PowerShell 5.1 remains available separately as powershell.exe when the operating system provides it. Installing PowerShell 7 does not replace Windows PowerShell.

4. Linux installation: prefer the supported package path for your distribution

Linux distributions use different package formats and package managers. Microsoft publishes installation guidance for supported Debian/Ubuntu-family and Red Hat Enterprise Linux-family systems. The preferred pattern is usually to register Microsoft's package repository for the supported distribution and then let the normal package manager install and update the powershell package.

After the Microsoft repository is configured, the package-manager step commonly resembles one of these platform-specific commands:

# Debian / Ubuntu family after the Microsoft repository is configured
sudo apt-get update
sudo apt-get install -y powershell

# RHEL family after the Microsoft repository is configured
sudo dnf install powershell

These commands require elevated privileges and are shown for orientation, not as the Chapter 01 lab. Repository bootstrap steps, supported distribution versions, signing keys, and package URLs can change. Do not copy an old repository-registration script from a blog. Use Microsoft's current page for your exact distribution and version.

Microsoft also publishes package files and binary archives for scenarios where a repository is not appropriate. That flexibility is useful in containers and controlled build environments, but it also transfers more responsibility to you for updates and dependency management.

5. macOS installation: use a supported package when support matters

Microsoft provides a signed macOS package installer for supported macOS versions. The resulting PowerShell executable is normally discoverable as pwsh, with a command path under /usr/local/bin in the documented package layout.

Package managers such as Homebrew can also offer PowerShell packages, but support ownership matters. Microsoft's current alternative-installation documentation describes Homebrew packaging as community-supported rather than Microsoft-supported. For a personal workstation that may be acceptable; for a production support contract, make the distinction explicit and verify the current documentation before standardizing on a channel.

The general lesson is broader than PowerShell: “available from my package manager” and “supported by the upstream vendor” are not necessarily the same statement.

6. Containers can provide a disposable PowerShell environment

A container is useful when you want a clean, temporary environment without changing the host installation. Microsoft's .NET SDK container images include PowerShell because the .NET SDK uses it in supported scenarios. At the time this lesson was generated, a current .NET 10 SDK image provides the runtime generation used by PowerShell 7.6 LTS.

docker run --rm -it mcr.microsoft.com/dotnet/sdk:10.0 pwsh

This command requires a working Docker installation and permission to run containers. The --rm option removes the container after it exits; -it allocates an interactive terminal. The image tag is part of your dependency contract, so a production pipeline should pin and update images deliberately instead of assuming a floating tag will remain byte-for-byte identical.

Containers do not eliminate platform differences. A Linux container running PowerShell is still a Linux environment. It will not make Windows-only modules or Windows APIs appear.

7. Understand PATH before blaming the installation

PATH is an environment variable containing directories that a shell searches when you type a command name without a full path. Each operating system has its own path syntax, but PowerShell gives you a cross-platform separator through [IO.Path]::PathSeparator.

$env:PATH -split [IO.Path]::PathSeparator

If pwsh is installed but its directory is not in PATH, another shell may fail to find it. If multiple versions are installed, the first matching executable found by the caller's search rules may not be the one you expected. Never infer the actual binary from the command text alone—inspect it.

Get-Command pwsh -ErrorAction SilentlyContinue |
    Select-Object Name, CommandType, Source, Version

(Get-Process -Id $PID).Path
$PSHOME

Get-Command pwsh tells you what the current PowerShell session would resolve if it were asked to launch pwsh. (Get-Process -Id $PID).Path tells you which executable is hosting the session you are already in. Those can differ if you have several installations.

8. Start, exit, and invoke PowerShell non-interactively

Typing pwsh in a terminal normally starts an interactive PowerShell session. Interactive means a person is present to type commands and inspect results. To leave the current PowerShell process, use:

exit

Automation often needs a non-interactive invocation: start PowerShell, run specific work, return an exit status, and terminate. Two fundamental entry points are -Command and -File.

# Run a command and exit.
pwsh -NoProfile -Command '$PSVersionTable.PSVersion'

# Run commands from a .ps1 script file and exit.
pwsh -NoProfile -File ./check-environment.ps1

-Command supplies command text. -File supplies the path to a script file. The quoting around -Command is interpreted first by the calling shell, so examples copied between Bash, PowerShell, and Windows Command Prompt may require different quoting. That cross-shell boundary is explored in Chapter 02.

-NoProfile avoids loading profile scripts, which is useful in CI and diagnostics where personal startup customizations should not silently affect results. It is not required for every interactive session.

9. Verification lab: prove which PowerShell you are running

This lab assumes PowerShell is already installed. It requires no administrative privilege and makes no machine-wide changes.

$verification = [pscustomobject]@{
    Version          = $PSVersionTable.PSVersion.ToString()
    Edition          = $PSVersionTable.PSEdition
    Host             = $Host.Name
    ProcessId        = $PID
    ProcessPath      = (Get-Process -Id $PID).Path
    PSHome           = $PSHOME
    Runtime          = [System.Runtime.InteropServices.RuntimeInformation]::FrameworkDescription
    OperatingSystem  = [System.Runtime.InteropServices.RuntimeInformation]::OSDescription
    WorkingDirectory = (Get-Location).Path
}

$verification | Format-List

$resolvedPwsh = Get-Command pwsh -ErrorAction SilentlyContinue
if ($resolvedPwsh) {
    "Resolved pwsh: $($resolvedPwsh.Source)"
    pwsh -NoProfile -Command '$PSVersionTable.PSVersion.ToString()'
}
else {
    "pwsh was not discoverable through the current PATH."
}

The child invocation is useful because it tests command discovery in addition to the current process. If the current shell is PowerShell 7 but Get-Command pwsh returns nothing, you may be in an unusual installation that was launched by full path but not added to PATH.

10. Installation and invocation failures to diagnose systematically

“pwsh: command not found” or “pwsh is not recognized.” Determine whether PowerShell is installed, then inspect PATH. Do not assume reinstalling is the first solution.

The wrong PowerShell version starts. Inspect command resolution and the current process path. Multiple versions may coexist, especially with ZIP installations or development builds.

A package-manager command from an old tutorial fails. Package repositories, distribution versions, keys, and URLs are time-sensitive. Return to the current Microsoft installation page for the exact operating system rather than improvising around a stale command.

A preview build became the default unexpectedly. Preview and production packages can have different executable/package naming depending on the platform. Keep preview environments intentionally separated and do not make them the baseline for course labs or production runners.

A command works interactively but not in CI. The CI runner may have a different PATH, no user profile, a different working directory, a different account, or a different PowerShell version. Lesson 4 builds the execution model needed to reason about that difference.

11. Knowledge check

12. Summary

PowerShell installation and terminal choice are separate concerns. Windows, Linux, macOS, and container environments have different supported installation channels, while pwsh is the modern cross-platform executable you ultimately invoke. A reliable setup is one you can identify: supported version, exact binary path, runtime, platform, and command-discovery behavior.

13. Further reading

• Microsoft Learn — PowerShell support lifecycle
• Microsoft Learn — Install PowerShell on Windows
• Microsoft Learn — PowerShell on Linux
• Microsoft Learn — Install PowerShell on Ubuntu
• Microsoft Learn — Install PowerShell on Debian
• Microsoft Learn — Install PowerShell on RHEL
• Microsoft Learn — Install PowerShell on macOS
• Microsoft Learn — PowerShell in Docker