Verb-Noun Commands, Aliases, Functions, Scripts, and Applications

1. The operational problem: names are not enough

In a small tutorial, a command name can look self-explanatory. In a real DevOps workstation, that same session may contain commands from PowerShell itself, your profile, imported modules, scripts on disk, cloud tooling, package managers, and native command-line programs. If two of those commands share a name, the text you type is not enough to tell you what will run.

Chapter 01 established the safe habit discover first, execute second. This lesson turns that habit into a precise model. PowerShell keeps metadata about commands, and Get-Command lets you inspect that metadata without running the target command.

Get-Command Get-Process |
    Select-Object Name, CommandType, Source, Version

Get-Command pwsh |
    Select-Object Name, CommandType, Source, Path

The first query normally identifies Get-Process as a cmdlet supplied by a PowerShell module. The second identifies pwsh as an application and shows its executable path. The exact paths and versions depend on your installation; the important evidence is the command type and source.

2. Verb-Noun is a discovery contract

Most PowerShell cmdlets and well-designed public functions use a Verb-Noun name such as Get-Process, Set-Location, or Remove-Item. The verb communicates the general action; the noun identifies the resource or concept. This is not cosmetic naming. A consistent vocabulary means you can search by intent.

Get-Command -Verb Get | Select-Object -First 12 Name, Source
Get-Command -Noun Process
Get-Verb | Select-Object -First 12 Verb, Group

Get-Verb lists approved verbs and their semantic groups. Module authors can technically create commands with unapproved verbs, but consistent approved verbs make commands easier to predict, search, document, and review. In team automation, discoverability is part of API design.

3. One command surface, several kinds of executable things

PowerShell uses the word command broadly. A command is something the engine can resolve and invoke, but different command types come from different places and have different behaviors.

Use -CommandType when you want to narrow discovery. Do not assume every machine has the same external applications, modules, functions, or aliases.

Get-Command -CommandType Cmdlet | Select-Object -First 5 Name, Source
Get-Command -CommandType Function | Select-Object -First 5 Name, Source
Get-Command -CommandType Alias | Select-Object -First 5 Name, Definition
Get-Command -CommandType Application pwsh | Select-Object Name, Path

4. Aliases are shortcuts, not stable production vocabulary

An alias is a short alternate name. Aliases are convenient when a human is typing interactively, but they hide intent in scripts and can vary across environments. A reviewer can understand Get-ChildItem immediately; gci requires alias knowledge.

Get-Alias gci
Get-Command gci | Format-List Name, CommandType, Definition
Get-Command Get-ChildItem | Format-List Name, CommandType, Source

Notice that Get-Alias answers “what does this alias point to?” while Get-Command answers the broader “what executable command does this name represent?” question. Production scripts normally use canonical command names because readability and portability are more valuable than saving a few keystrokes.

5. Command precedence decides which same-named command wins

When you type a bare command name with no path, PowerShell must choose among possible matches. For commands already available in the session, the documented precedence is Alias → Function → Cmdlet → external executable/script. A path-qualified command bypasses that name search and runs the command at that path.

Get-Command Get-Date -All |
    Select-Object Name, CommandType, Source, Definition

-All is critical when troubleshooting conflicts because ordinary Get-Command Name emphasizes the command PowerShell would normally resolve first. A conflict can be created safely inside a child scope so your session is not permanently changed:

& {
    function Get-Date { 'function shadows the cmdlet in this scope' }

    Get-Command Get-Date -All |
        Select-Object Name, CommandType, Source

    Get-Date
    Microsoft.PowerShell.Utility\Get-Date
}

Inside the script block, the function named Get-Date wins over the cmdlet. The module-qualified form Microsoft.PowerShell.Utility\Get-Date deliberately selects the cmdlet. When the script block ends, the temporary function disappears with that child scope.

6. Resolve command paths and filesystem paths with the right tool

For a native application, Get-Command exposes the executable path. For a script, use its command metadata or an explicit path. Resolve-Path solves a different problem: it resolves an existing PowerShell provider path, such as a filesystem path. It is not the general command-name resolver.

$pwshCommand = Get-Command pwsh -CommandType Application
$pwshCommand.Path

Resolve-Path .
Resolve-Path (Join-Path $HOME '.')

This distinction prevents a common category error: command discovery asks “what will this name execute?” while path resolution asks “what existing provider item does this path identify?”

7. Modules explain where many commands come from

A module groups PowerShell commands and related resources into a reusable unit. The Source property shown by Get-Command often names the module that exported a cmdlet or function. That source matters when two modules expose similar names or when a CI runner is missing a dependency.

Get-Command Get-ChildItem |
    Select-Object Name, Source, Version

Get-Module -ListAvailable |
    Sort-Object Name |
    Select-Object -First 10 Name, Version, Path

Do not interpret Get-Module -ListAvailable as “everything is loaded.” It inventories modules PowerShell can discover from module paths. Later chapters cover importing, authoring, packaging, and versioning modules in depth.

8. Lab: investigate an unfamiliar command without running it first

Your task is to investigate Get-Random as if you encountered it in a repository you did not write. Do not start by executing it. Gather evidence first.

$name = 'Get-Random'

$command = Get-Command $name
$command | Select-Object Name, CommandType, Source, Version

Get-Command $name -All |
    Select-Object Name, CommandType, Source

Get-Command -Noun Random
Get-Help $name -Synopsis

Write down answers to these questions: Is it a cmdlet, function, alias, script, or application? Which module/source provides it? Are there multiple commands with the same name? What neighboring commands share the noun? What does the synopsis say it does? Only after answering those questions, run a harmless example from its help.

Get-Help Get-Random -Examples | Select-Object -First 20
Get-Random -Minimum 1 -Maximum 10

9. Common discovery mistakes

Assuming a short name is portable. An alias or function in your profile might not exist in CI. Prefer canonical names in checked-in automation.

Searching only the filesystem. Cmdlets and functions are not discovered by scanning PATH. Use PowerShell command metadata.

Looking at only one match. Name conflicts are exactly when Get-Command -All matters.

Confusing installed modules with imported state. -ListAvailable tells you what can be discovered from module locations, not what is currently imported.

Running an unknown command just to see what it does. Discovery and help exist so experimentation can start with metadata rather than side effects.

10. Knowledge check

11. Summary

PowerShell is intentionally discoverable. Verb-Noun naming gives commands a searchable vocabulary; command metadata distinguishes cmdlets, functions, filters, aliases, scripts, applications, and their sources; precedence explains which duplicate name wins; and module-qualified or path-qualified invocation lets you be explicit. The scalable skill is not memorizing command names—it is proving what a name means in the current environment.

12. Further reading

• Microsoft Learn — about_Command_Precedence
• Microsoft Learn — Get-Command
• Microsoft Learn — Get-Alias
• Microsoft Learn — about_Aliases
• Microsoft Learn — about_Modules