In the latest entry in the official PowerShell Blog, Jeffrey Snover leaves a little tidbit about a change coming on the next CTP of PowerShell V2:

The cmdlet keyword is going away and we'll just have function. Notice that now you can specify the [Parameter()] attribute on parameters.  When you do that, we treat the function like a cmdlet.

I don’t mind getting rid of the cmdlet keyword; honestly, but is the new syntax that much of an improvement? So now instead of an explicit keyword telling you whether something is a function of a cmdlet, you have an attribute spilled around the function parameters? Not sure if that’s good or not, but sounds confusing to me, at first glance.

Maybe what rubs me the wrong way, however, is the [Parameter] attribute. I’m OK with using an attribute to specify the metadata associated with the parameters, honestly. But the whole Param + [Parameter] thing just reads redundant and ugly:

Can anyone more familiar with this chime in? Am I the only one slightly bothered by this?

I tend to fire up Windows Explorer instances from my prompt very often, either on the current directory or in other spots. I was pretty used to using the “explorer /e,<path>” command from CMD.EXE but I never had figured out exactly how to use it on PowerShell and have it work reliably: Paths with spaces always caused it to open the default documents folder instead.

Finally sat down and played with it until I got it right:

Silly little helper PowerShell function that I’ve been finding useful lately when doing some debugging:

Neil Houghton asked a couple of days ago if I could share my PowerShell prompt() function. Here's what my prompt looks like:

I tried to keep my prompt relatively short while still on a single line. There are two things I care about in my prompt: The machine name I'm working on (useful when I have VMs opened) and the current path, in abbreviated form.

Thus, my prompt() function looks like this:

The abbreviation of the current directory is partially inspired by Unix (use ~ if it's under the $HOME) and partially by how GVim shortens paths for its tab captions:

Here's the function that takes care of this:

One thing to keep in mind regarding shorten-path: I do a very simple replace of $HOME by ~. The reason it works correctly is that I ensure in my profile script that the $HOME variable has a fully qualified path and "completed" using the resolve-path command. I also modify what the home directory is under PowerShell by using a trick I've described previously.

PowerShell, Customization

I thought it would be fun to bring up a list of some small things I love about using PowerShell as my default command line / scripting tool on the Windows platform. Without further introduction, here they are:

Switching to Network Shares

One of the most annoying limitations of the old cmd.exe was that it provided almost no support for network shares that were not mapped as drives.

The PowerShell provided model, fortunately, didn't make this mistake, so you can use set-location to switch to a network share and execute commands there just like in any other local folder:

Location Stacks

Like other shells, PowerShell supports pushing folders into a stack and then popping them back out, making it a lot easier to navigate around a few folders without having to remember the complete paths each time. You manipulate the location stack using the push-location and pop-location commands, which are aliased to pushd and popd respectively.

I find this very useful when running doing builds or when working with Vim and some scripting language.

The PowerShell implementation, however, has a couple of advantages:

1. It works on the provider model, so you can push/pop more than just file system locations. For example, you could use the location stack to move around the registry.
2. It supports multiple stacks: You can keep multiple, named location stacks at the same time by simply using the -stackName parameter: 
   
   

The contents of the location stacks are stored as part of your PowerShell Session State, and you can see the contents of each stack by using the get-location command:

Notice that the default stack will always have an empty string ('') as its name.

It's .NET-based

The fact that PowerShell is based on the .NET Framework can be confusing to some people due to some of the underlying complexity of the framework leaking to the shell (like value types).

However, for a developer like me, this is a great thing. It means that a lot of the things I used to create small C# apps for, like quickly trying out a framework class/method, I can now try interactively on the shell. It also means that there is a lot of functionality already built, right at my fingertips that can be used very quickly.

Here's an example: I was recently working on a new Virtual Machine I had just setup and needed to generate a new GUID. I'm very used to going to the command line and running the old uuid.exe utility to do this, but, unfortunately, I had not installed the Windows SDK on the VM yet and was not planning to. With PowerShell, though, this was not a problem:

Shell Introspection

Another aspect that I really enjoy about PowerShell is the built-in introspection features. It's a lot easier to learn the shell when all the information about what's available and the objects you're manipulating is easily accessible.

Here are some of the introspection features I like:

• The get-command command. Great way to see what commands are available. Coupled with get-help, it's a really nice way to figure something out.
• The built-in providers. One really nice feature of PowerShell is that functions, aliases and variables are all exposed as providers, meaning you can list them / examine them to your hearts content using the standard location commands like get-childitem. Just try running "ls function:" or "ls variable:" next time.
• The $MyInvocation, $ExecutionState and $Host variables give you access to plenty of information about the execution environment, as well as lots of options for manipulating it.

No need for Calc.exe

I used to constantly start calc.exe to do a quick calculation. Since PowerShell is a full scripting language, however, I now do most of those quick calcs by directly entering expressions into the PowerShell prompt.

It's a heck of a lot easier and very convenient for me since I always keep around a PowerShell prompt opened and ready to go.

PowerShell