Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

The Voice of the DBA

Steve Jones is the editor of SQLServerCentral.com and visits a wide variety of data related topics in his daily editorial. Steve has spent years working as a DBA and general purpose Windows administrator, primarily working with SQL Server since it was ported from Sybase in 1990. You can follow Steve on Twitter at twitter.com/way0utwest

The Powershell Challenge–Day 9 The Pipelines, deeper

This is part of my Powershell Challenge, to learn more about PowerShell (PoSh) using the Learn Windows Powershell 3 in a Month of Lunches book by Don Jones.

The authors note this is an optional chapter, one that isn’t necessarily one you need to read. After going through it, I’m not sure I agree, especially as I’m not completely sure I grasp all the contents, though I do think they will be handy.

When you pipe output from one command to another in Unix, it’s really a text stream. Just as it would be written to stdout, it’s sent to the next command. That means your commands need to handle text as inputs.

In PoSh, if I understand this, that’s not the case. The inputs into commands are through parameters for the most part. That means that the output from one command, which is a collection of objects, needs to be accepted in the next. For many commands, that doesn’t quite work.

There are two methods of sending in parameters. One is input ByValue, which is a parameter binding method. In this method, PoSh looks at the type of parameter being sent in, in essence the object type (or data type) and matches to a parameter if the parameter accepts pipeline input. Not all do, and you need to read the HELP for a command to see which parameters accept pipeline input. That seem mis-named to me. It’s ByType, not ByValue in my mind, but I’m certainly not a PoSh expert.

The other way is ByPropertyName, which is as it implies, by name. The object coming in has its name matched with the parameters of the command on the other side of the pipeline.  That makes more sense, though there are times that the names don’t match.

That’s where you can then create custom properties with the Select-Object syntax that creates name/value pairs from your input. It looks like handy, not too complex, but cumbersome syntax. I’ll have to play with this more as I had to work through some exercises and carefully watch my parens and braces (opening and closing) as I typed in some commands.

One thing that frustrated me slightly with these exercises is that a bunch of them looked at multiple machines, and I don’t have a domain at the present time with matching credentials. I couldn’t figure out (easily) how to connect to another machine with custom credentials for Get-Process and Get-Service, but I also was running short of time this lunch, so I skipped.

The lab was analysis without using PoSh, since many people reading the book might not be admins on a domain. I got most of the answers right, but not always the explanation. I certainly think I need to play with this more, and that means I’ll stand up a domain here soon that I can use. I need to do that anyway.

The custom properties, along with the introduction of parens for order of operations, make this a must read chapter for me. I think the authors shouldn’t caveat this one at all.


Filed under: Blog Tagged: career, powershell, syndicated

Comments

Leave a comment on the original post [voiceofthedba.wordpress.com, opens in a new window]

Loading comments...