A question that sometimes comes up is, “When do I write a PowerShell provider instead of a cmdlet?” To explain that, it is useful to understand how PowerShell distills management concepts for administrators.

In the pre-PowerShell world, the command-line management experience is fairly fractured. You have a huge number of awkwardly named commands, with no way to quickly determine what they mean. Many of them perform nearly identical actions, but have very different names. The image above illustrates a chaotic mix of commands that work primarily on files and directories.

One of the amazing features of PowerShell is its amazing reach.  You can interact with the file system, the registry, certificate stores, COM, WMI, XML, cmdlets, providers … the list seems to go on forever.

One important extension point is the ability to seamlessly interact with .NET DLLs. These are most commonly shipped in SDKs, and many people have made use of this.  For example:

• Sharepoint: http://blogs.flexnetconsult.co.uk/colinbyrne/PermaLink,guid,1665700b-e0de-4b8a-bb1c-014d6fbcf2db.aspx
• Team Foundation Server: http://netcave.org/PermaLink,guid,f1840c93-fc6f-4673-bdde-0af89add5ab9.aspx
• Microsoft Operations Manager: http://mow001.blogspot.com/2006/06/powershell-and-mom-2005.html

When pre-built API DLLs don’t suit your need, you have yet another option – writing your own! If you are comfortable with any of the .NET languages, it is quite simple to compile a DLL and load it into your PowerShell session.

Here’s a useful bit of line noise that I came up with when I wanted to put some quoted text into email.  Starting with unwrapped text in the clipboard:

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

To give a glimpse into the writing process behind my upcoming “Windows PowerShell - The Definitive Guide” (O’Reilly,) I’ll occasionally post entries “as the author sees it.”  The first in this series shows how to search the PowerShell help content for a phrase or pattern.

Program: Get-HelpMatch¶

Both the Get-Command and Get-Help cmdlets allow you to search for command names that match a given pattern. However, when you don’t know exactly what you are looking for, you will more often have success searching through the help content for an answer. On Unix systems, this command is called Apropos.  Similar functionality does not exist as part of the PowerShell’s help facilities, however.¶

Oren Eini recently ran into some performance problems while using PowerShell to count the number of lines in a source tree:

_I wanted to know how many lines of code NHibernate has, so I run the following PowerShell command…
(gci -Recurse | select-string . ).Count
The result:
(Graphic of PowerShell still working after about 5 minutes, using 50% of his CPU.)
Bummer.
_

The performance problem from this command comes from us preparing for a rich pipeline experience in PowerShell that you never use.  With only a little more text, you could have run even more powerful reports:

You may have noticed that we changed the location of the default profiles yet again! 

The one in “My Documents” is now under “WindowsPowerShell,” rather than “PsConfiguration.”
The one in “All User’s Documents” is now under the installation root.

Since you are probably wondering why, I’ve updated my last explanation: The Story Behind the Naming and Location of PowerShell Profiles.

Several people have been churning out screencasts lately, and they are really great resources.

On the Channel9 front, David Aiken recently posted two DFO Show screencasts:

• Introducing Windows PowerShell
• Amazon S3 meets Windows PowerShell (fantastic!)

In addition, Doug Finke and the Lab49 team just posted an overview of some PowerShell features – Variables, Arrays, Hashtables, Functions, and PsObject.

For interactive learners, the screencast medium is a great resource.  Not only do you get to watch over somebody’s shoulder, but the vocal accompaniment also provides the “Proximity Effect” benefit of working under the guidance of an expert.

Now that DasBlog 1.9 has been released, I’ve finally upgraded.  Everything appears to have gone well, and I’m really happy with some of the new themes available.  You won’t necessarily notice this if you only read the site through your RSS reader, so why don’t you come on down and check out the new look? :)

Please let me know if you see anything broken!

My O’Reilly PowerShell Quick Reference is now available – a 120-page guide (in PDF format) that provides the essential reference material for your day-to-day use of PowerShell.  With a concise explanation at your fingertips, there is no need to memorize esoteric topics like regular expressions and string formatting specifiers.

Aside from its straight factual reference material, the Quick Reference also provides an enormous amount of value by distilling large bodies of knowledge into their most usable forms, including:

As people begin to explore PowerShell, the question often comes up – “Will PowerShell support the cmdlet or language feature <foo>?”

For example (from the newsgroup,) “Is there a way to get the unmodified contents of a file – since Get-Content splits it into lines?”  Or from Occasionally Rabid Programmer, “… Is there a zipping PowerShell class yet?”  For many of these questions, the answer is, “Yes. Since PowerShell gives you access to all of the .Net Framework, you could also ask ‘Does the .Net Framework support <Foo> yet?’”