Creating Aliases
To create a new alias we use the commandlet New-Alias.
-Name and -Value are required and should not contain any spaces, the description is optional but can help you remember why you created this alias.
The Value is not limited to commandlets, you can also use executable files on your disk by providing a full path to them.
When aliasing commandlets you can even use all flags of the aliased commandlet while referencing the alias -tab completion will also work as expected.
If you ever get an error trying to create an alias there is a high probability there is already an alias using that name. To overwrite it you can make use of the -Force switch, even though I would recommend investigating the existing alias before by running Get-Alias .
Viewing Aliases
PowerShell comes with many aliases already enabled, you can view them by executing Get-Alias – This will show you all aliases enabled in the current session.
Additional filtering is possible on multiple criteria, like the -Definition or -Name of the alias. Both
parameters support wildcards, which allows you to, for example, find any alias for Get- commandlets.
Persisting Aliases
Everything we did up to now will vanish once you close your current PowerShell session, as setting aliases is not a permanent operation.
Therefore, we want to define our aliases in the profile file. If you want to learn how that works, read the article in MS Documentation.
Inside your profile you can use the same command to create your aliases as in your interactive session.
To get the aliases you may have already created in your session you can just filter your history.
If you want some inspirations on common aliases I collected, check out my personal profile I recently open sourced.
Limitations
Aliases sadly have one glaring limitation, you can not use the parmameters of the commandlet you are aliasing inside the value of your commandlet.
For example, this will not work. There will be no error on creation, but running it PowerShell will not be able to locate the commandlet.
There is a way to work around this, however it is quite limited, as it removes the capability to tab complete or even use any of the other parameters the aliased commandlet can provide.
Unfortunately I am not aware of a way to solve this limitation, if you are, please reach out to me, and I am happy to add it for anyone else interested.
Addendum: Shortly after this article was released, ScriptRunner’s very own Achim Wieser provided one possible solution for this issue, which contains the use of an advanced function as a wrapper.
You can find a more detailed description of his approach on Marco Kamners Blog.
When Not To Use Aliases
Aliases are a great way to speed up your day-to-day work, however they should not be used in scripts meant for long time usage or distribution.
The most important reason is compatibility, imagine you have an alias lr as described above and use it in your scripts. Anyone else running your script will then be greeted by an error message on running the script and reaching the alias.
Or even worse, there could be a different command behind the alias, breaking the whole script or altering its effects.
Working in VSCode using aliases will, by default, be shown as a warning and the default ms-vscode.powershell extensions even provides an automated way of resolving any alias in your code by opening the command bar and typing PowerShell: Expand Alias.
Conclusion
As this article shows, using PowerShell aliases is quite simple and a good way to save time when processing recurring and repetitive tasks. Similarly, you could use aliases to help you remember certain cmdlets and make it easier to work with your personal use cases.
If you’re interested in more tips on how you can improve your daily work with PowerShell, make sure to have a look at our article about the Top 10 PowerShell Commands for Troubleshooting Windows Problems.
