PowerShell Essentials: Navigating the Console and Running Cmdlets Safely

Getting into a PowerShell Session

PowerShell is an interactive console (a “shell”) where you type commands and see results immediately. You can also run scripts later, but beginners should start by practicing in a live session.

Exercise: Open PowerShell and identify what you’re running

• Open Windows PowerShell or PowerShell from the Start menu.
• Optional: open as Administrator only when you truly need it (many read-only commands work without admin rights).
• Run:

$PSVersionTable

This prints a table-like view showing your PowerShell version and environment details. It’s a safe, read-only command and a good first test that your session is working.

Understanding the Prompt and Where You Are

The prompt is the text shown before your cursor. It usually includes your current location (folder). Many beginner mistakes come from running a command in the wrong place.

Exercise: Check your current directory and list what’s there

Get-Location

Get-ChildItem

Common output patterns you’ll see:

• Single values (like a path) returned as plain text or an object displayed as text.
• Lists of items (files/folders) shown in rows.
• Tables with column headers (PowerShell formats many objects as tables by default).

Tip: If you see a lot of output, you can page it:

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

Get-ChildItem | More

Cmdlet Naming: Verb-Noun and Why It Matters

Most built-in PowerShell commands are cmdlets. They follow a consistent naming pattern: Verb-Noun. This makes commands easier to guess and search for.

Exercise: Discover cmdlets by verb

Get-Command -Verb Get

This is a discovery command: it helps you explore what’s available without changing anything.

Basic Command Syntax: Cmdlet, Parameters, and Values

A typical cmdlet call looks like this:

Verb-Noun -ParameterName Value

Key ideas:

• Parameters start with - and refine what the cmdlet does.
• Some parameters are switches (on/off flags) and don’t need a value, e.g. -Recurse.
• PowerShell is generally flexible about spacing, but you should be consistent and readable.

Exercise: Use a parameter to narrow results

Get-ChildItem -Path $env:USERPROFILE

$env:USERPROFILE is an environment variable that points to your user profile folder. This is safer than hard-coding a path you might mistype.

Read-Only First: Safe Starter Cmdlets

When you’re learning, start with cmdlets that only read information. They build confidence and teach you output patterns.

Exercise set: Run these and observe the output

• List running processes:

Get-Process

• List services (may be long):

Get-Service | More

• List commands that match a keyword:

Get-Command *service*

As you run these, notice that PowerShell output is often structured like a table. That’s PowerShell formatting objects for display; the underlying data is richer than what you see.

Verifying What a Command Will Do (Before It Does It)

Before running a command that might change something, verify three things:

• What command am I actually running?
• What target (path, computer, service, process) will it affect?
• What will happen if it matches more items than I expect?

Step 1: Inspect help and examples

Use help to confirm purpose and parameters. Focus on examples first.

Get-Help Get-ChildItem -Examples

Get-Help Remove-Item -Examples

Even if you are not going to run Remove-Item yet, reading its examples helps you recognize risky patterns (like recursion).

Step 2: Preview targets with a read-only command

If you plan to act on files, preview the exact set of items first. For example, before deleting log files, list them:

Get-ChildItem -Path $env:TEMP -Filter *.log

Only after you are confident the list is correct should you consider an action cmdlet (and then use safety switches when available).

Interpreting Common Output Patterns (and What to Do Next)

Tables vs. lists

Some cmdlets show a table by default (good for scanning). Others show a list (good for details). You can request a list view to see more properties:

Get-Process | Format-List

If you want to see “everything” PowerShell knows about an object, inspect its members:

Get-Process | Get-Member

Errors: read them, don’t ignore them

PowerShell errors often include the cmdlet name, the line, and a message. Common beginner causes include:

• Typos in cmdlet names or parameters.
• Wrong path (folder doesn’t exist, or you’re in a different directory than you think).
• Insufficient permissions (especially when touching system locations).

When you hit an error, re-check your location and the exact command spelling before trying again.

Safe Usage Patterns (Dedicated)

1) Start with discovery commands

Use discovery cmdlets to explore what exists and what commands are available:

• Find commands:

Get-Command *event*

• Read help/examples:

Get-Help Get-EventLog -Examples

• Check your current context:

Get-Location

2) Prefer non-destructive actions while learning

Choose Get-* cmdlets first. When you need to change something, try to do it in a controlled, reversible way (for example, create a test folder in your profile rather than working in system folders).

Exercise: Create a safe sandbox folder (non-system location)

$sandbox = Join-Path $env:USERPROFILE 'Desktop\PS-Sandbox'

New-Item -Path $sandbox -ItemType Directory

Get-ChildItem -Path $sandbox

This keeps your practice away from sensitive locations like C:\Windows or C:\Program Files.

3) Confirm paths and targets explicitly

Many cmdlets accept a -Path parameter. Be explicit rather than relying on “current directory” assumptions.

Exercise: Compare implicit vs explicit targeting

Get-ChildItem

Get-ChildItem -Path $env:USERPROFILE

When you are about to run a command that modifies items, being explicit about -Path reduces accidental changes in the wrong directory.

4) Use -WhatIf and -Confirm when available

Many cmdlets that change state support -WhatIf (simulate) and -Confirm (ask before acting). These are key safety tools.

Exercise: Simulate a change without making it

First, create a test file in your sandbox:

$testFile = Join-Path $sandbox 'test.txt'

Set-Content -Path $testFile -Value 'hello'

Now simulate removing it:

Remove-Item -Path $testFile -WhatIf

PowerShell will tell you what it would do, without doing it. When you’re ready, you can add confirmation instead of simulation:

Remove-Item -Path $testFile -Confirm

Note: Not every cmdlet supports -WhatIf. If it’s supported, you’ll see it in help:

Get-Help Remove-Item -Full

5) Be careful with wildcards and recursion

Wildcards like * can match more than you expect, and -Recurse can affect entire folder trees.

Exercise: Preview wildcard matches safely

Before acting on a wildcard, list what it matches:

Get-ChildItem -Path $sandbox -Filter *.txt

If you ever consider using -Recurse, preview with a read-only listing first:

Get-ChildItem -Path $sandbox -Recurse

Quick Checklist: Avoiding Common Beginner Mistakes

• Typos: If a cmdlet isn’t found, re-check spelling and hyphens (Verb-Noun). Use Get-Command *keyword* to search.
• Wrong directory: Run Get-Location before commands that depend on where you are. Prefer explicit -Path.
• Accidentally targeting too much: Preview with Get-ChildItem before using action cmdlets; be cautious with * and -Recurse.
• Not checking help: Use Get-Help <Cmdlet> -Examples to confirm intent and syntax.
• Forgetting safety switches: Use -WhatIf to simulate and -Confirm to require approval when available.
• Confusing PowerShell with CMD: Some commands share names but behave differently. When unsure, verify with Get-Command <name> to see what will run.
• Running as Administrator unnecessarily: Use normal sessions for learning and read-only tasks; elevate only when required.