What’s in a name? Using prefixes in PowerShell.

What’s in a name? Using prefixes in PowerShell.

Rate This
  • Comments 3

We’ve talked about this in the past but it’s time for a reminder.  PowerShell uses prefixes in front of nouns to avoid name collisions.  Imagine how many collisions there would be if people used the noun “USER” directly.  Instead, we have cmdlets *-ADUser, *-VPNUser, and *-RDUser.  The use of the prefix avoids name collisions.  When there is a name collision, the customer must specify the full name of the cmdlet.  Did you know that the full name of Get-ADUser was actually ActiveDirectory\Get-ADUser?  How would you feel if you had to type that every time you wanted to invoke that command? 

The use of prefixes also makes it easy to find related components.  Look how easy it is to find all the PowerShell settings by searching for variables with the “PS” prefix:

 

 

It is important to use prefixes.  There are two other rules you need to know:

  1. The prefix for PowerShell is “PS”.  If you use the “PS” prefix, we can and will collide with you.
  2. There are two scenarios where PowerShell will use generic nouns:  When we cover a system resource (e.g. *-Process) or where we provide a pluggable framework for an area (e.g. Drives, Jobs, Events, etc.).

Moving forward, we anticipate continuing to create modules, environment variables, file extensions, and other content types using the “PS” prefix and creating additional pluggable frameworks where we will use generic nouns.
If you don’t use a prefix or use the PS prefix, you are setting yourself up for a collision.   

 

We don’t want to create naming conflicts – that’s why we have insisted on the use of prefixes from the very early days on PowerShell and why we started using the “PS” prefix. 

To Sum Up

Use noun prefixes and avoid the “PS” prefix to deliver a great customer experience and minimize/avoid name collisions.

 

Thanks,

 

Jeffrey Snover and John Slack

Leave a Comment
  • Please add 3 and 1 and type the answer here:
  • Post
  • I've still not wrapped my head around this. Is the recommended way to write modules without prefixed names, and use DefaultCommandPrefix in the module manifest to provide a default prefix?

    For example a function Get-Changeset (in source control) with a module manifest defaultcommandprefix=P4 => Get-P4Changeset.

    Since most people only uses one source control system, it would be nicer for the users to be able to use Get-Changeset without the prefix, but it doesn't seem to be possible to say import-module Perforce -prefix '' (that still returns the defaultcommandprefixed name.

    Is is reasonable then to not use a prefix and let the few users who are using multiple systems use import-module -prefix to resolve conflicts?

    Can you elaborate with examples on how you best see this implemented?

    /Staffan

  • Good Tip - good to know!

  • Also advantageous when exporting cmdlets from a remote session into a locally created module.

    technet.microsoft.com/.../ff720181.aspx

Page 1 of 1 (3 items)