Add a Couple of Functions to PowerShell Profile
Summary: Microsoft Scripting Guy, Ed Wilson, adds a couple of new functions to his Windows PowerShell console profile.
Microsoft Scripting Guy, Ed Wilson, is here. I have heard that necessity is the mother of invention. For me, annoyance is the mother of scripting. What I mean is that when it comes time for me to write a script (something short and quick), I only do it after I am tired of typing the same command over and over again. For example, consider the first two functions I recently added to my Windows PowerShell profile…
Load and unload modules
Everyone knows we have automatic module loading in Windows PowerShell 3.0. But not everyone knows that when it comes time to use Get-Command, if I have not loaded the modules, an error generates, as shown here.
If this is the case, why don’t I just add the command to load all modules into my profile? The reason is speed of launching. For example, on my laptop, it consistently takes 16 seconds to load all of my modules. This is shown here:
PS C:\> Measure-Command {Import-AllModules}
Warning: To run some commands exposed by this module on Windows Vista, Windows
Server 2008, and later versions of Windows, you must start an elevated Windows
PowerShell console.
Days : 0
Hours : 0
Minutes : 0
Seconds : 16
Milliseconds : 43
Ticks : 160435770
TotalDays : 0.000185689548611111
TotalHours : 0.00445654916666667
TotalMinutes : 0.26739295
TotalSeconds : 16.043577
TotalMilliseconds : 16043.577
I want to be able to load or to unload all of the modules, but do it only when I need to do so. Therefore, this becomes a good excuse for writing a couple of functions.
I have been typing the commands to load and to unload all modules for at least a year (as long as I have been using Windows PowerShell 3.0). Finally, it got to me, and I decided to write the simple functions that follow. Oh by the way, to make the functions easier to use, I created a couple of aliases for them too. Here are the two functions:
Function Import-AllModules
{Get-Module -ListAvailable | Import-Module}
Function Remove-AllModules
{Get-Module -ListAvailable | Remove-Module}
Set-Alias -Name ram -Value Remove-AllModules
Set-Alias -Name iam -Value import-allmodules
Finding commands
Get-Command works great. But the default output is not what I normally would do. For example, because of all the cmdlets and functions, the output invariably scrolls, so I need to pipe the results to More. In addition, I normally am looking for cmdlets from the same module, so I like to sort by the module. I therefore came up with this function that I call Get-Commands (I also created an alias for it).
Function Get-Commands
{
Param($verb,
$noun)
Get-Command @PSBoundParameters | Sort-Object module | more
}
Set-Alias -Name gcms -Value get-commands
About the only thing notable here, is the use of $psBoundParameters. This cool automatic variable keeps track of parameters that are supplied to a function. I need to know if –Verb or –Noun or both –Verb and –Noun are supplied so I can create the syntax for the Get-Command cmdlet.
In the past, I would have needed to use a series of If / Else / Elseif types of construction to get the correct syntax. By using $PSBoundParameters, I do not need to do this. I simply pass whatever is supplied as arguments to the function to the command line via $PSBoundParameters. I then sort the results on the Module parameter and send the results to the More command. It works great, and saves me a lot of repetitive typing.
Removing the AD: drive
Part of the slowness in loading the Active Directory module is due to the creation of the AD: drive. I do not use this drive all the time, but I do use the Active Directory cmdlets on nearly a daily basis. So I created a function to disable creating the AD: drive. Here is the function:
Function Remove-ADDrive
{$Env:ADPS_LoadDefaultDrive = 0}
I load it directly via my Windows PowerShell profile. If I want the AD: drive, I just comment out the line that calls the Remove-ADDrive function.
Admin or not?
The last thing I did was modify the title of my Windows PowerShell console based on if I have Admin rights. My Test-ISAdministrator function has been talked about (and copied) widely, so I am not going to repeat it here. I use it to see if I have Admin rights. If I do, I set the Windows PowerShell console title to SUPER PowerShell dude! If I do not have Admin rights, I set the title of the Windows PowerShell console to Regular PowerShell dude. The function is shown here:
Function Set-ConsoleConfig
{
if(-not (Test-IsAdministrator))
{$Host.ui.RawUI.WindowTitle = "Regular PowerShell dude"}
else {$Host.ui.RawUI.WindowTitle = "SUPER PowerShell dude!"}
} #end function set-consoleconfig
The Windows PowerShell console when launched with non-elevated permissions is shown here:
That is all there is to adding a couple of functions to my profile. 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