Tag Archives: PowerShell

Pimp your Prompt

bling2If you are like me and live in PowerShell, then you spend a great deal of your day looking at your PowerShell prompt. That little indicator in the console and ISE that usually shows where you are. That little part of your PowerShell world is defined by a built-in function called Prompt. You can easily see the function like this:

This prompt is from PowerShell v4 but I’m pretty sure it is the same function that was used in v3. PowerShell v2 has a different function.

Did you notice that the newer function has a help link? Try it:

help prompt -online

You’ll get the online version of the about_prompts help topic. The great thing about the prompt function is that you can change it. I’ve posted a variety of prompts over the years. But here are 4 more for you to try out. These prompts should work in v3 and later. Most of the functions are simple additions to the standard prompt and should work for both the console and ISE. To try out the prompt you can paste the function into your PowerShell session. To make it “permanent”, insert it into your PowerShell profile script.

Include PowerShell Version

This prompt inserts the PowerShell major version into your prompt.
version-prompt

Include Admin

This prompt will test if you are running as Admin and if so, it inserts [ADMIN] in red text.
adminprompt

Include Computername

Do you like how a remoting session shows you the computer you are connected to? Why not have that all the time? All I’ve done is insert the local computername from the Computername environmental variable.

computername-prompt

Auto Export Command History

This last version serves up a twist on transcription. When you run a transcript you get the command and results. But maybe all you want is a record of all the commands you ran. Sure, you could export command history at the end of your session, but you have to remember to do so and if you exceed your maximum history count, you’ll miss commands. In this prompt, everytime you hit enter, it gets the last command you ran and appends it to a log file. The log file is created in your PowerShell directory and uses the naming format of the PowerShell host, without spaces, a time stamp (YearMonthDay) and the process ID of the current PowerShell session. This allows you to keep multiple PowerShell sessions with separate logs. The log file will only record the command if it is different than the last one you ran. This also allows you to hit Enter without doing anything and not fill up your log.

If you temporarily paste in one of these Prompt functions, but don’t like it, you can simply restart PowerShell to get your original prompt. Or you can use this function to restore it.

This is handy to put into your PowerShell profile if you are experimenting with prompts. The Restore-Prompt simply defines a new Prompt function in the global scope. I’m using the default PowerShell prompt but you change it to whatever you wanted.

If you are doing something cool with your prompt, I hope you’ll share.

Friday Fun: A Random PowerShell Console

crayonsThis week I thought we’d have a little fun with the PowerShell console and maybe pick up a few scripting techniques along the way. Today I have a function that changes the foreground and background colors of your PowerShell console to random values. But because you might want to go back to your original settings without completing restarting PowerShell the function allows you to reset to your original values. Oh, and it also supports -Whatif. Here’s what I came up with.

The function will not work properly in the PowerShell ISE so I’ve included some code at the beginning to see if it is running in the ISE. If so, the command displays a warning and bails out. This is a scenario where using Return is completely acceptable as I want to return out of the pipeline without doing anything. I could have used a command like this: Return “This command only works in the PowerShell console.” but that would have written a string object to the pipeline and I don’t want anything to go to the pipeline. Plus, I prefer to use Write-Warning for messages like this.

When you run the command, it tests for the existence of some variables, $savedfg and $savedbg, that are defined in the global scope. You’ll notice the use of the global: prefix. If they are not defined, then the assumption is that this is the first time the command has been run and the variables will be defined with the current values of the $host.ui.rawui.foregroundcolor and $host.ui.rawui.backgroundcolor values. Later, if you use -Reset, the command will use these values to restore your original settings.

Otherwise, the command gets a random color for the System.ConsoleColor enumeration for the background and then another random color for the foreground, that is different than the randomly selected background color.

When you look at the code, you will see that I am specifying in the cmdletbinding attribute that the function supports ShouldProcess. That could also be written [cmdletbinding(SupportsShouldProcess=$True)] but that seems redundant to me. Anyway, the command to make the change, $host.ui.rawui.backgroundcolor= $bg, by itself doesn’t know anything about ShouldProcess and -WhatIf. But I can add my own code using an If statement.

The value for the ShouldProcess() method is the text you see as part of the “…performing operation on target…” message. The text is the target.
set-randomconsol-whatif

All I’ve done is define a variable, $msg, to make the line of code easier to read. As you can see, it is not that difficult to add your own support for -WhatIf. And now, if you get a little bored, mix it up for a fresh perspective. I’ve even included an alias, src, in case you have to type in a console where you can’t see what you’re typing.

Have a terrific weekend.

So you need to write a PowerShell script

lightbulb-idea So…you have decided to write a PowerShell script or have at least identified a need. What do you do first? If you say “Google or Bing”, I’d say you are wrong. In my opinion, when you are developing a PowerShell script, searching for an existing script is not the first step. Sure, you will likely find something, but….

There are many online sources of PowerShell scripts and code samples. However, from my experience the quality is all over the board. Sure, you might find a great example. But unless you have a great deal of PowerShell experience, how will you judge? Sadly, many script and code samples I see don’t follow community accepted best practices, don’t follow the PowerShell paradigm or are simply bad scripts. There is also absolutely no guarantee that the script or code sample you download will work correctly (and safely) in your environment.

Personally, I would recommend that you open your script editor and start laying out a series of comments about what it is that you need to accomplish. If you are using the ISE you might even use regions to outline your script. This task helps your organize your work, and when you are finished, the script is documented? All you have to do is write the code to fulfill the comments. Yes, that might be difficult and maybe even a little time consuming at first, but that’s the point. You will be learning much more than by simply copy and pasting something of dubious quality you found online. Even more importantly, you will be developing something that you know will work in your environment.

Get stuck? Then sure, look online to find examples of how someone used a particular cmdlet or function. But try to find several examples and “average” them out. Perhaps even better would be to post in the forums at PowerShell.org and ask for specific help on a sticky problem. You’ll likely get several responses. And knowing the quality of the average PowerShell.org forum member, I’d feel very comfortable with their responses.

Over time, as you gain more PowerShell experience, you will be better able to assess the quality of online PowerShell scripts and samples. I still think you should develop on your own from scratch, but I also think you’ll find the process goes much faster.