Using PowerShell Aliases: Best Practices
Summary: Microsoft Scripting Guy, Ed Wilson, demystifies some of the confusion surrounding using Windows PowerShell aliases. Microsoft Scripting Guy, Ed Wilson, is here. “Don’t use aliases!” I hear this all the time from various people on the Internet. I am constantly asked at Windows PowerShell user groups, at TechEd, and at community events such as Windows PowerShell Saturday, if it is alright to use an alias.
What’s the big deal anyway?
An alias is a shortcut name, or a nickname, for a Windows PowerShell cmdlet. It enables me to type a short name instead of a long name. Is this a big deal? You bet it is. Windows PowerShell ships with around 150 predefined aliases. The longest cmdlet name is 30 characters long. Yes, that is right—30 characters. This is a very long command name. If I have to type New-PSSessionConfigurationFile very many times, I am definitely going to seek an alias. Luckily, npssc is available to do the job.
Note I used the following code to determine the length of cmdlet names and their associated aliases.
gal | select definition, @{label=”length”; expression={$_.definition.length}} | sort length
What about tab expansion?
Tab expansion works to help to reduce the typing load when working with Windows PowerShell. One of the issues with tab expansion is that in Windows 8, there are over 2000 cmdlets and functions. Therefore, it takes more tabs to expand the correct cmdlet name. In the previous example, rather than having to type 30 characters to get access to the New-PSSessionConfigurationFile cmdlet, I can type New-P and hit the Tab key a few times. On my laptop, I have to press the Tab key four times before New-PSSessionConfigurationFile appears on the command line. Typing five characters with New-P and pressing the Tab key four times is nine key strokes to enter the New-PSSessionConfigurationFile command. The npssc alias is only five key strokes, so I save four key strokes every time I use the alias instead of using Tab expansion.
Use aliases when working interactively at the console
For me, it is a best practice to use Windows PowerShell aliases when I am working interactively in the Windows PowerShell console. This is because it is the best way to reduce the amount of typing. It also reduces the amount of memorization needed. For example, is it Get-ChildItem or Get-ChildItems? I do not need to remember either one, because I can use LS, DIR, or GCI as an alias when calling that particular cmdlet.
Note One of the most basic mistakes I see with beginners who are just learning Windows PowerShell is that they do not use Tab expansion, nor do they use aliases. Instead they attempt to type the entire Windows PowerShell cmdlet name—and invariably, they get it wrong. So use aliases, or use tab expansion, but do not attempt to type the long cmdlet names. In addition, if there is a Windows PowerShell cmdlet that I use on a regular basis that does not have a currently defined alias, I like to create an alias and store it in my Windows PowerShell profile. In this way, I make sure I have easy access to any Windows PowerShell cmdlet regardless of the length of the actual cmdlet name.
When not to use aliases
With all the goodness that aliases bring to the table, I might be inclined to use aliases all the time. There is a disadvantage, however. Aliases can be hard to read. Some aliases make sense: Sort for Sort-Object, Where for Where-Object. Others, such as sv, sbp, sc, and rv are rather obscure. One of the nice things about Windows PowerShell code is that it is very readable. Therefore, Get-Service does not need much explanation—it returns service information. But gsv, needs a bit of explanation before I know that it is an alias for Get-Service. So, what I gain in speed of typing, I loose in ease of understanding. When working interactively at the Windows PowerShell console, the primary purpose is to accomplish something. I want to get the task completed accurately, and timely. I do not want to expend any extra effort to accomplish the task. When I close the Windows PowerShell console, everything I typed is lost (unless I have enabled the transcript or exported my command history). On the other hand, when I write a Windows PowerShell script, the purpose is to have something I can use over and over again. So I am creating an artifact that has intrinsic value, and that I can use as a management tool. The goal here is reusability, not speed of development and execution. Therefore, I do not want to use aliases in my script because it hinders readability and understanding.
Note A fundamental tenant of script development is that the better I can understand my script, the fewer errors it will contain, and the easier it will be to fix any errors that may arise. In addition, because scripts are reusable, it also will be easier to modify the script in the future. Time spent in script development is an investment in the future. This does not mean I have to give up the ease of using aliases when I am writing a Windows PowerShell script. I wrote a function that I include in my Windows PowerShell profile that replaces all aliases with the actual cmdlet name: Modify the PowerShell ISE to Remove Aliases from Scripts. In this way, I have the ease of being able to use Windows PowerShell aliases, with the readability of full cmdlet names later. Join me tomorrow when I will talk about more cool Windows PowerShell stuff. I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace. Ed Wilson, Microsoft Scripting Guy
Light
Dark
0 comments