I was reading very interesting post from Jeffrey Hicks called PowerShell Picasso today and I must say that I agree with him 99%.

If you know the way I script, then you have probably noticed that it is hybrid code between PowerShell and .NET. For example I don’t like ForEach-Object cmdlet – from my perspective, it makes code much LESS readable. I would compare it to question sentence in English and in Spanish. In Spanish, every question sentence begins with question mark (for example ¿Cómo estás?) and you immediately know it is going to be the question.

For same reason, I always use ForEach ($X in $Y) {…}. I find it much easier to undestand $X. than $_… If I have a quick peek at code, using $Service.Status immediately tells me what I need, while $_.Status requires me to read preceding code to understand what type of object is $_. Organizing code to blocks is my preferred method (while many Powershell guys organize code to sentences ).

Second side effect is that by using .NET syntax, people much quickly adopt the fact that Powershell is based on .NET object and is object-oriented language. Later on, these administrators can read and understand MSDN documentation or examples that are written in C#. To summarize it, my point is that for many people, Powershell can be used as entry point to .NET world (.NET for Administrators).

I fully agree with rest of the Jeffrey’s article. “Problem” as I see it is that most people use Posh in interactive mode – and there is huge difference in writing few functions for yourself and trying to build complex framework out of Powershell (just checked – my framework currently consists of almost 4000 files, even though it is based on modules). In case you don’t think about readability of your code, you will get lost when you will need to write the complex modules (thousands of lines).

Martin

Today I run into pretty nasty bug in Powershell.

One of jobs that we support for S4Matic is used to automatically export\import any objects from (and to) SCCM. Packages are exported in universal format, so there are no internal IDs used and you can easily take these packages and import them to completely different environment.

To simplify process, we export all data to XML format and then import it if needed.

We support exclusion list to specify which properties you DON’T want to migrate. For example you don’t want to export\import information like creation date or last modification time.

At beginning, I used hashtable to define this. I wanted to move this to external configuration file – of course my first option would be XML format.

I was surprised when my scripts stopped working suddenly. After little bit of digging, I noticed that all scripts failed to export all “Name” properties.

Of course it makes sense if you think about it for a while – my approach won’t work if class where I store my data contains property with same name.

To my surprise, XmlElement DOESN’T contain property called Name. Of course psbase does:

$X.definition | gm | Where {$_.Name -eq "Name"}

$X.definition.psbase | gm | Where {$_.Name -eq"Name"}

   TypeName: System.Management.Automation.PSMemberSet

Name MemberType Definition
—- ———- ———-
Name Property   System.String Name {get;}

This is how I am testing for property:

$X.definition.name -is [object]

So even though Get-Member doesn’t display it in list of properties, Powershell is still using it – which is little bit scary, because that it can be really hard to predict how code will behave.

Martin

At Login Consultants I’m using a simple script to automatically document our scripting framework. After some reports of my colleagues about this script not working on Windows 7 I decided to start testing. Here’s what I found:

PowerShell v1.0:

PowerShell CTP 2.0 (V3):

Anyone got some idea what is going on?

A while ago my colleague Martin Zugec posted about a Gotcha concerning return values from subroutines. Read the full story here:

http://martinzugec.blogspot.com/2008/08/returning-values-from-fuctions-in.html

Some things may seem a little strange when working with PowerShell when coming from other scripting languages and especially when coming from a development background. What I noticed today in one of my scripts took me quite a while to troubleshoot.

The problem concerned a comparison between two values using “-eq”. I retieved a value from a subroutine and compared it to a string value. The code looked something like this:

$returnValue = Somesubroutine(xxxx…
if ($returnValue -eq “xxxxxxx”) { do something }

Because of an error in my subroutine the returning value was a boolean instead of a string. Still I wondered why the “do something” was executed. I mean, $True can’t possibly equal “xxxxxxx” right? Try the following on your commandline:

if ($true -eq “blahblahblah”) {write-host “They are the same”}

Have you tried it? The text “They are the same” will actually be written to the console! How weird is that?

PowerShell has a very powerfull typing system. This typing (or casting if you will) will automagically convert the type of an object to an other type if needed. However, PowerShell should only do this IF NO INFORMATION IS LOST.

In this case I’m not sure what is happening. Either the text “blahblahblah” is actually converted to a boolean and since it exists it will be converted to $true. Or, the if statement encounters a “$true” and will then immediatly yield true and execute the command ‘write-host “They are the same”‘.

Whatever is the case: GOTCHA!