At work, I have a library of modules stored on a network share. In order to make things work well when I’m not on the network, I include the network share in my PSModulePath, but later in the PSModulePath I point to a local copy of the library.
Since installing the 5.0 preview (which I love, btw), I’ve seen some really strange errors, like this one:

Obviously, I am not redefining the set-variable cmdlet in my scripts. I’ve had similar kinds of errors with clear-host and other “core” cmdlets. FWIW, the cmdlets that error while loading the profile seem to work fine after everything is done loading. Clearing nonexistent paths out of the PSModulePath makes the errors go away.
If you have to include network shares in your PSModulePath, I would recommend adding them in your profile, and use test-path to make sure that they are available before making the modification. T

I’ll chalk this one up to it being pre-release software. It’s encouraging to see the PowerShell team continue to deliver new and exciting features with the speed that they have.

-Mike

Ok…that’s a strange title, but let me finish before you decide its lame. (On a side note, I’m a dad, so my humor tends to run in that direction naturally).

I see lots of examples in books and on the web about how to use pipeline input to functions. I’m not talking about how to implement pipeline input in your own advanced functions, but rather examples of using pipeline input with existing cmdlets.
The examples invariably look like this:

‘server1’,’server2’ | get-somethingInteresting –blah –blah2

This is a good thing. The object-oriented pipeline is in my opinion the most distinguishing feature of PowerShell, and we need to be using the pipeline in examples to keep scripters from falling back into their pre-PowerShell habits. There is an aspect of this that concerns me, though.

How many of you are dealing with a datacenter comprised of two servers? I’m guessing that if you only had two servers, you probably wouldn’t be all gung-ho about learning PowerShell, since it’s possible to manage two of almost anything without needing to resort to automation. Not to say that small environments are a bad fit for PowerShell, but just that in such a situation you probably wouldn’t have a desperate need for it.
How would you feel about typing that example in with five servers instead of two? You might do that (out of stubbornness), but if it were 100, you wouldn’t even consider doing such a thing. For that matter, what made you pick those specific two servers? Would you be likely to pick the same two a year from now? If your universe is anything like mine, you probably wouldn’t be looking at the same things next week, let alone next year.
My point is that while the example does show how to throw strings onto the pipeline to a cmdlet, and though the point of the example is the cmdlet rather than the details of the input, it feels like we’re giving a wrong impression about how things should work in the “real world”.

As an aside, I want to be very clear that I’m not dogging the PowerShell community. I feel that the PowerShell community is a very vibrant group of intelligent individuals who are very willing to share of their time and efforts to help get the word out about PowerShell and how we’re using it to remodel our corners of the world. We also are fortunate to have a group of people who are invested so much that they’re not only writing books about PowerShell, they’re writing good books. So to everyone who is working to make the PowerShell cosmos a better place, thanks! This is just something that has occurred to me that might help as well.

Ok..back to the soapbox.

If I’m not happy about supplying the names of servers on the pipeline like this, I must be thinking of something else. I know…we can store them in a file! The next kind of example I see is like this:

Get-content c:\servers.txt | get-somethingInteresting –blah –blah2

This is a vast improvement in terms of real-world usage. Here, we can maintain a text file with the list of our servers and use that instead of constant strings in our script. There’s some separation happening, which is generally a good thing (when done in moderation :-)). I still see some problems with this approach:

• Where is the file? Is it on every server? Every workstation? Anywhere I’m running scripts in scheduled tasks or scheduled jobs?
• What does the file look like? In this example it looks like a straight list of names. What if I decide I need more information?
• What if I don’t want all of the servers? Do I trust pattern matching and naming conventions?
• What if the file moves? I need to change every script.

I was a developer for a long time and a DBA for a while as well. The obvious answer is to store the servers in a table! There’s good and bad to this approach as well. I obviously can store more information, and any number of servers. I can also query based on different attributes, so I can be more flexible.

• Do I really want to manage database connections in every script?
• What about when the SQL Server (you are using SQL Server, right?) gets replaced. I have to adjust every script again!
• Database permissions?
• I have to remember what the database schema looks like every time I write a script?

What about querying AD to get the list? That would introduce another dependency, but with AD cmdlets I should be able to do what I need. But…

• What directory am I going to hit (probably the same one most of the time, but what about servers in disconnected domains?)
• Am I responsible for all of the computers in all of the OUs? If not, how do I know which ones to return?
• Does AD have the attributes I need in order to filter the list appropriately?

At this point you’re probably wondering what the right answer is. The problem is that I don’t have the answer. You’re going to use whatever organizational scheme makes the most sense to you. If your background is like mine, you’ll probably use a database. If you’ve just got a small datacenter, you might use a text file or a csv. If you’re in right with the AD folks, they’ve got another solution for you. They all work and they all have problems. You’ll figure out workarounds for the stuff you don’t like. You’re using PowerShell, so you’re not afraid.

Now for the payoff: Whatever solution you decide to use, hide it in a function.

You should have a function that you always turn to called something like “get-XYXComputer”, where XYZ is an abbreviation for your company. When you write that function, give it parameters that will help you filter the list according to the kinds of work that you’re doing in your scripts. Some easy examples are to filter based on name (a must), on OS, the role of the server (web server, file server, etc.), or the geographical location of the server (if you have more than one datacenter). You can probably come up with several more, but it’s not too important to get them all to start with. As you use your function you’ll find that certain properties keep popping up in where-object clauses downstream from your new get-function, and that’s how you’ll know when it’s time to add a new parameter.

The insides of your function are not really important. The important thing is that you put the function in a module (or a script file) and include it using import-module or dot-sourcing in all of your scripts.
Now, you’re going to write code that looks like this:

Get-XYZComputer –servertype Web | get-somethinginteresting

A couple of important things to do when you write this function. First of all, make sure it outputs objects. Servernames are interesting, but PowerShell lives and breathes objects. Second of all, make sure that the name of the server is in a property called “Computername”. If you do this, you’ll have an easier time consuming these computer objects on the pipeline, since several cmdlets take the computername parameter from the pipeline by propertyname.

If you’re thinking this doesn’t apply to you because you only have five servers and have had the same ones for years, what is it that you’re managing?

• Databases?
• Users?
• Folders?
• WebSites?
• Widgets?

If you don’t have a function or cmdlet to provide your objects you’re in the same boat. If you do, but it doesn’t provide you with the kind of flexibility you want (e.g. it requires you to provide a bunch of parameters that don’t change, or it doesn’t give you the kind of filtering you want), you can still use this approach. By customizing the acquisition of domain objects, you’re making your life easier for yourself and anyone who needs to use your scripts in the future. By including a reference to your company in the cmdlet name, you’ve making it clear that it’s custom for your environment (as opposed to using proxy functions to graft in the functionality you want). And if you decide to change how your data is stored, you just change the function.

So…do you know where your servers are? Can you use a function call to get the list without needing to worry about how your metadata is stored? If so, you’ve got another tool in your PowerShell toolbox that will serve you well. If not, what are you waiting for?
Let me know what you think.

–Mike

Before I cover this specific code smell, I should probably explain one thing. The presence of code smells doesn’t necessarily mean that the code in question isn’t functional. In the example I gave last time (the extra long method), there’s no reason to think that just because a method is a thousand lines long that it doesn’t work. There are lots of examples of code that is not optimally coded that works fine nonetheless. The focus here is that you’re causing more work: Either up-front work in that the code is longer or more complicated than necessary, or later on, when someone (maybe you?) needs to maintain the code.

With that said, we should talk about aggregating output using a collection object and the += compound assignment operator. This is such a common pattern in programming languages that it’s a hard thing not to do in PowerShell, but there are some good reasons not to. To help understand what I mean, let’s look at some sample code.

function get-sqlservices {
param($computers)
    foreach ($computer in $computers){
           $output+=get-wmiobject -class Win32_Service -filter "Name like 'SQL%'"
    }
    return $output
}

$mycomputers='localhost','127.0.0.1',$env:COMPUTERNAME
measure-command{
get-sqlservices -computers $mycomputers | select -first 1
}

Before we discuss this code let me be clear: this is not great code for several reasons. For the purposes of discussion, though, let’s just look at how the output is handled. As I mentioned, this is how you’d do something like this in most programming languages and it works fine. On my laptop it ran in 723 milliseconds. If we change the list of computers to a longer list it takes considerably longer:

$mycomputers=('localhost','127.0.0.1',$env:COMPUTERNAME) * 100

Days : 0
Hours : 0
Minutes : 0
Seconds : 51
Milliseconds : 486
Ticks : 514863437
TotalDays : 0.000595906755787037
TotalHours : 0.0143017621388889
TotalMinutes : 0.858105728333333
TotalSeconds : 51.4863437
TotalMilliseconds : 51486.3437

Changing the function to send the output to the pipeline looks like this:

function get-sqlservices2 {
param($computers)
    foreach ($computer in $computers){
           get-wmiobject -class Win32_Service -filter "Name like 'SQL%'"
    }
}

$mycomputers=('localhost','127.0.0.1',$env:COMPUTERNAME) * 100
measure-command{
get-sqlservices2 -computers $mycomputers | select -first 1
}

Days : 0
Hours : 0
Minutes : 0
Seconds : 0
Milliseconds : 478
Ticks : 4782609
TotalDays : 5.53542708333333E-06
TotalHours : 0.00013285025
TotalMinutes : 0.007971015
TotalSeconds : 0.4782609
TotalMilliseconds : 478.2609

The code doesn’t look much different. The only changes are that we’re not assigning the output of the get-wmiobject cmdlet to anything and we don’t have an explicit return. This is a point of confusion to most people who come to PowerShell from a traditional imperative language (C#, Java, VB, etc.). In a PowerShell script, any value that isn’t “captured” either by assigning it to a variable or piping it somewhere is added to the output pipeline. The “return value” of the function is the combination of all such values and the value in a return statement (if present). So in this case, the output of the new function is the same as the output of the second. Changing it to use the pipeline didn’t change the value at all. So why is this considered a code smell? The reason is that the second script runs faster than the first did. In fact, it runs faster with 300 computers (100 copies of the list of 3) than the first did with 3 computers. Why is it so much faster? In PowerShell 3.0, the implementation of select-object was changed to stop the pipeline after the number of objects requested in the -first parameter. In other words, even though we passed 300 servers to the function, it stopped after it got the first result back from get-wmiobject from the first server.
You’re not always going to be using -first, but even when you’re not the values in the pipeline are available to downstream cmdlets before the function is done completing (if you don’t use +=). If you’re simply sending the output to the console you will begin to see the results immediately rather than having to wait. Another issue arises when your aggregating function has throws an exception before it’s done. If you didn’t hit the return statement, you won’t see any results at all. Being able to see the results up to the point of the error will probably help you track down where the error was. What if there were thousands of servers (or your dataset was considerably larger for some other reason)? Your process would eat memory as it built a huge collection. With pipeline output there’s no reason for the process to be using much memory at all. Finally, with pipeline output there’s one less thing to keep track of. One less variable means one less place to make a mistake (accidentally use = at some point instead of +=, misspell the variable name, etc.).

I hope you can see that with PowerShell, following this common pattern is not a good thing.

Let me know what you think.

Mike

A code smell is something you find in source code that may indicate that there’s something wrong with the code. For instance, seeing a function that is over a thousand lines gives you a clue that something is probably wrong even without looking at the specific code in question. You could think of code smells as anti-“Best Practices”. I’ve been thinking about these frequently as I’ve been looking through some old PowerShell code.

I’m going to be writing posts about each of these, explaining why they probably happen and how the code can be rewritten to avoid these “smells”.

A few code smells that are specific to PowerShell that I’ve thought of so far are:

1. Missing Param() statements
2. Artificial “Common” Parameters
3. Unapproved Verbs
4. Building output using +=
5. Lots of assignment statements
6. Using [object] parameters to allow different types

Let me know if you think of others. I’ll probably expand the list as time goes on.

-Mike

You’ve probably been told all your life that you should learn from your mistakes. I agree with this statement, but I prefer always to learn from other people’s mistakes. In this post, I’ll give you an opportunity to learn a bit more about PowerShell by watching me mess up. What a deal!

I was helping a colleague with a script he was writing. His script wasn’t very complicated. It simply read in a list of computernames from a text file and tried to access them via WMI. He wanted the script to keep track of the ones that were inaccessible and output that list to a second text file for later review.

I was helping him via IM (not the best approach, but we were both busy with other things), and what we came up with was something like this.

$errorservers=@()
$servers=get-content c:\temp\servers.txt
foreach($server in $servers){
     try {
        #Do some stuff here
     } catch {
       $errorServers+=$server
     }
}
$errorServers | export-csv c:\temp\ErrorServers.txt

Imagine my surprise when he emailed me the error output (which we both were expecting to be a list of unreachable servers) and it looked like this:

#TYPE System.String
"PSPath","PSParentPath","PSChildName","PSDrive","PSProvider","ReadCount","Length"
"C:\temp\computers.txt","C:\temp","computers.txt","C","Microsoft.PowerShell.Core\FileSystem","2","14"


When I was able to observe the script running, I had him output the value of $errorServers, and when he did, the output looked exactly like we had expected. Changing the last line to

$errorServers | out-file c:\temp\ErrorServers.txt

fixed the script as far as he was concerend. But where did the “mystery columns” come from?

It turns out when you read a file with get-content, PowerShell “decorates” the strings it returns with information about where the string came from (what file, folder, drive, provider, line, and length of the read data). When we sent the string to the console for output, the console printed the value of the string (since that’s how the console outputs strings). However, when we sent the string to a file with export-csv, the cmdlet looked for properties that made sense to be columns and found the “decorations” that were provided by get-content. I had no idea that PowerShell was doing this because I don’t generally look for properties on strings (as a side note, the $profile variable set by PowerShell also has some “hidden” properties).

To see this more clearly, I did the following:

PS> get-content C:\temp\computers.txt | select -first 1 | format-list *

kyndig

PS> get-content C:\temp\computers.txt | select -first 1 | format-list * -force

PSPath : C:\temp\computers.txt
PSParentPath : C:\temp
PSChildName : computers.txt
PSDrive : C
PSProvider : Microsoft.PowerShell.Core\FileSystem
ReadCount : 1
Length : 6

I was able to learn something useful from my mistake this time. Hope you did, too.

–Mike

One of my earliest (posts was about implementing an “identity function” in PowerShell to assist in typing lists of strings without bothering with commas.

The function I presented was this:

function identity{
    return $args
}

I recently saw (in a Scripting Games entry) that you don’t need to define your own function for this. write-output works just fine.

For example:

$values=write-output apple orange banana

Mike