When it comes to PowerShell, I have always had something of a love/hate relationship with aliases. On one hand, many of the PowerShell aliases that exist are completely cryptic and I think that they make it a lot more difficult to figure out what a line of code does. That’s why I rarely use aliases in the PowerShell code that I include in my articles.
The flip side to that is that PowerShell aliases can make the transition from the Windows Command Prompt to PowerShell a little bit easier. Many of the old DOS commands have been implemented in PowerShell in the form of aliases. For example, the PowerShell cmdlet for retrieving a list of the files in the current folder is Get-ChildItem. The DOS command for doing the same thing is DIR. Even so, the DIR command works in PowerShell, because it is actually an alias for the Get-ChildItem command.
Lots of aliases
When I first began working heavily with PowerShell, one of the things that really surprised me was just how many aliases are actually supported. If you ever want to check out a list of the available aliases, just enter the Get-Alias command. This will cause PowerShell to display a list of its aliases. You can see a partial sample in the screen capture below.
Incidentally, you can easily export the entire list to a spreadsheet (a CSV file) by using the Export-Alias cmdlet. Here is an example of the command:
Export-Alias -Path “Alias.csv”
With that said, let’s pretend that you are writing a script and you will be using a particular cmdlet many times throughout the script, and you want to save yourself some typing by using the cmdlet’s alias instead. How do you find out if there is an alias available for that cmdlet?
If you want to know if an alias exists, just enter the Get-Alias cmdlet, followed by the -Definitions parameter and the name of the cmdlet that you want to find an alias for. If for example, you wanted to find an alias for the Get-ChildItem cmdlet that I mentioned earlier, you could type this command:
Get-Alias -Definition Get-ChildItem
As you can see in the next image, there are sometimes multiple aliases for a single cmdlet.
Of course, the technique works in reverse too. If, for example, I knew that the DIR command was not a true PowerShell command and was probably an alias for something, I could find out what the “real” command is by entering the Get-Alias cmdlet, followed by DIR. You can see how this works in the screenshot below.
Thinking outside the PowerShell box
The thing about PowerShell aliases that I always get a kick out of is that they sometimes allow you to do some things that are counterintuitive. As I mentioned earlier, for example, DIR was an old DOS command for listing the contents of a folder. Back then, that was the only thing that you could do with the DIR command. Because in PowerShell DIR is an alias for the Get-ChildItem cmdlet, you can do some things with DIR that were impossible using the native DIR command, such as browsing the registry. You can see an example of that below. Using an alias doesn’t unleash any functionality that cannot be achieved through the alias’s corresponding PowerShell cmdlet, but rather provides the illusion of breathing new life into old DOS commands.
PowerShell also allows you to create your own aliases. Let’s pretend for a moment that I am too lazy to type DIR and I want to be able to just type D instead. All I would have to do is create a new alias called D. Here is how it works:
New-Alias -Name “D” -Value Get-ChildItem -Description “A shortcut to the Get-ChildItem cmdlet”
If you look at the screenshot below, you can see that when I initially enter the D command, I get an error message. Next, I used the New-Alias cmdlet to create the D alias, and then I tried the D command again, this time successfully.
I can take things a step further and use the Get-Alias cmdlet to retrieve a list of aliases for the Get-ChildItem cmdlet. As you can see in the next figure, D is now listed as an alias.
But remember, they are not permanent
The most important thing that you need to know about creating your own aliases is that the alias is temporary and is only valid in the current session. In fact, if you were to open an additional PowerShell window, your new alias would not be recognized within that window. Fortunately, there is a way to keep from losing all of your work.
Earlier I mentioned that you could use the Export-Alias cmdlet to create an alias spreadsheet. You can use this cmdlet to create an alias spreadsheet after creating custom aliases. The next time that you launch a PowerShell session, you can use the Import-Alias cmdlet, followed by the name of the CSV file (such as Import-Alias Alias.csv) to resurrect your custom aliases. That way, you can use your custom aliases in the current session without having to recreate them from scratch.
PowerShell aliases: Not for sharing
Custom PowerShell aliases can be very helpful in that you can use them to create a set of commands that are easier to type or easier to remember than the native PowerShell cmdlets. It is worth noting, however, that you should be careful about using custom aliases within a PowerShell script. After all, your custom aliases are only valid in the current session (unless you have imported a list of aliases), which means that scripts that make use of custom aliases will fail unless PowerShell has been made aware of those aliases. As such, it’s probably OK to use custom PowerShell aliases in scripts that you create for your own purposes, but you should avoid using them in scripts that you plan to share with other people.
