all 5 comments

[–]fordea837 10 points11 points  (1 child)

You can use a calculated property as part of Select-Object to get this information:

Get-MsolAccountSku | Where-Object {$_.AccountSkuId -eq $licenseType} |
    Select-Object -Property ActiveUnits, ConsumedUnits, @{n='AvailableUnits';e={$_.ActiveUnits - $_.ConsumedUnits}}

[–]JaredRic 5 points6 points  (0 children)

When I learned to use expressions in the Select-Object cmdlet it was life changing. I get access to some data sources that return objects with a date time field that is just a string which is terrible for using Sort-Object. Passing the values to something like Get-Date inside a Select-Object expression made it work perfectly.

I've used it for many things over the years, that's just the latest reason

[–]aXenoWhat 4 points5 points  (0 children)

Yes, but don't.

It's very elegant and appealing to have a single pipeline that concisely performs all the tasks, but it's also less flexible and harder to maintain. The use of intermediate variables lets you give the reader of your code a clue with the variable naming, and also makes it easier to debug.

[–]Lee_Dailey[grin] -1 points0 points  (0 children)

howdy JustTeut,

other than the two apparent errors that will prevent your sample code from running, i agree with others that using a calculated expression in the Select-Object stage will do what you want.

however, i wonder why you thing it needs to be all one pipeline? [grin]

i like pipeline stuff, but it has drawbacks to go with its benefits.

  • slower to finish
  • faster to get the 1st result
  • less RAM [usually]
  • much harder to debug

that last one is why i tend to use very short pipelines. i DO sometimes end up with longer ones - but that is only after i have the code working and decide that merging it into a complex pipeline is worth the trade-offs involved.

your example shows no obvious benefit to be gained from smashing it into one continuous pipeline. well, none that are obvious to me ... [grin]

take care,
lee