Favorite PowerShell Tips and Tricks
Summary: Microsoft Scripting Guy, Ed Wilson, talks about Windows PowerShell tips and tricks from the Charlotte User Group meeting.
Microsoft Scripting Guy, Ed Wilson, is here. Last week was a special meeting at the Charlotte Windows PowerShell User Group. It followed immediately after the Windows PowerShell Summit, and as a result, the user group included five members of the Windows PowerShell team, nearly a dozen MVPs, and at least that many Microsoft employees. All in all, there were nearly a hundred people in the room, and that, I believe, makes it the largest Windows PowerShell User Group meeting so far in Charlotte.
Lee Holmes led the meeting, and the subject was Windows PowerShell tips and tricks. But instead of Lee standing in front of us, doing a show-and-tell, he showed a trick, and then asked for one from the audience. The trick had to be something that people used on a regular basis, which means they are useful, not simply esoteric. The meeting was amazing, and this week I am going to share the best with you in Tips and Tricks Week.
Add resource usage to your Windows PowerShell prompt
This tip actually incorporates several tips at once. One tip involves making sure that you read the automatic variables list and descriptions from time-to-time (see about_Automatic_Variables). As Lee Holmes said, “If the Windows PowerShell team takes the time to create an automatic variable and to include it in everything, then it is obviously important.”
There are a lot of automatic variables, and some of them only appear at certain times and at certain places. So, one cannot simply use Get-Variable and see all of the automatic variables.
Two more tips involve creating and using a Windows PowerShell profile and modifying the Windows PowerShell prompt. For more information, read these Hey, Scripting Guy! Blog posts:
One of the attendees at the Charlotte Windows PowerShell User Group meeting mentioned that he once ran into trouble with a long running Windows PowerShell job that soaked up a lot of resources. To help to indicate what was going on with the long running job, he modified his Windows PowerShell prompt to include information about Windows PowerShell resource usage.
The Windows PowerShell prompt, is simply a function that is named “prompt.” It is a bit different, depending on whether one is running in the Windows PowerShell console or in the Windows PowerShell ISE. But if I use the following command, I will always return the appropriate prompt function:
PS C:\> Get-Content Function:\prompt
"PS $($executionContext.SessionState.Path.CurrentLocation)$('>' * ($nestedPromptLevel
+ 1)) "
# .Link
# http://go.microsoft.com/fwlink/?LinkID=225750
# .ExternalHelp System.Management.Automation.dll-help.xml
I like to copy the contents of the function, so I have something to begin playing around with:
From looking over the automatic variable list, I found a $pid automatic variable. This variable displays the process ID for the Windows PowerShell process that hosts the current Windows PowerShell session. This is shown here:
PS C:\> $pid
2972
This means that I can use the Get-Process cmdlet to retrieve performance information about the current Windows PowerShell process. This is important to do because there could be multiple Windows PowerShell processes running, and I want to return the correct one. This technique is shown here:
PS C:\> Get-Process -Id $pid
Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id ProcessName
——- —— —– —– —– —— — ———–
1093 79 167652 196780 1070 11.44 2972 powershell_ise
Note It is important to supply the –ID parameter when using $pid with Get-Process because the default parameter for Get-Process is name, and an error occurs if I use $pid and do not supply the appropriate parameter. In other words, the cmdlet is not smart enough to recognize a number, and realize that I am supplying a process ID.
In addition to the process ID, I want to include information about the CPU, virtual memory, working set, and paged memory. To do this, I store the results from Get-Process into a variable:
$ps = Get-Process -id $pid
Then I use parameter substitution and the format operator to supply the process information. I do this because I also want to format the numbers to two decimal places to make things easier to read. I can write my prompt function, and when I run it, it will change my Windows PowerShell ISE prompt in the output pane. The function is shown here:
function prompt
{
$ps = Get-Process -id $pid
"PS PID: $pid PM(M) {0:N2} WS(M) {1:N2} VM(M) {2:N2} CPU(s) {3:N2}
$($executionContext.SessionState.Path.CurrentLocation)$('>' * `
($nestedPromptLevel + 1))" `
-f ($ps.PM/1MB), ($ps.ws/1MB), ($ps.vm/1MB), $ps.cpu
}
Here is the modified output pane after I run the function:
Now I start a background job, and see what happens. Here is a simple background job that will run for a while, and use a bit of memory and CPU time:
start-job -ScriptBlock {
1..1000000000 | % {[math]::Cos([math]::Sin($_)) } }
As shown here, as soon as I run my background job, I can see that the memory changes and the CPU time is going up:
Because this is a background job, I can continue to work in my Windows PowerShell ISE. I can, for example, look at other things in the Windows PowerShell output pane. Here, I look at all processes that have a name that includes PowerShell
Because I have not added this particular prompt function to my Windows PowerShell ISE profile, when I close the Windows PowerShell ISE and open it again, the prompt reverts to the original prompt. This is shown here:
But, even if I did add the function to my Windows PowerShell ISE profile, I can always open the Windows PowerShell ISE by using Run and specifying the –NoProfile parameter:
There is a beginning for Windows PowerShell tips and tricks. Tips and Tricks Week will continue tomorrow when I will talk about more cool 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