Profile cover photo
Profile photo
Rob Campbell
Rob's posts

An observation made while working on my Event 5 entry for the scripting games - filter vs foreach-object

Dedupe 100,000 items with a hash table, using foreach-object, vs doing the same operation with a filter:

$array = (1..1e3) * 100

(measure-command {
                 $ht =@{}
                 $array | foreach-object {$ht[$_]=$true}

(measure-command {
                  filter Dedupe {$ht[$_]=$true}
                  $array | Dedupe

Post has shared content

$test10_vals =@{$false= 'Ten or less';$true = 'More than ten'}
$x = 12
$test10_vals[($x -ge 10)]
What's the most elegant way people have found to implement a ternary/conditional operator (like iif, or "expr ? val_if_true : val_if_false") in PowerShell?

Bonus points if you can tell me why it still doesn't exist in the language! ;o(

Post has attachment

Post has attachment
Lots of talk about PS V3 (W8 beta), and scripting "best practices" (SG2012) going around, got me to thinking.

It seems to me that "best practice" (at least a good practice for an enterprise admin) would be to write scripts using Begin and End blocks

and to try to minimize the End block, and splat everything that uses more than one parameter.

When it comes time to make that script run as a background or remote job or in a workflow there's a good chance you'll need to do some re-factoring to get the parameters and variables passed to it.

If you've got the bulk of your code defined in your Begin block as functions, that should translate directly to the initialization script of the job. That leaves you with just the End block to re-factor for the scriptblock of the job. If you've got that reduced to just calling functions from your Begin block and splatting the parameters then that becomes a process of cutting the hash tables out of the End block and pasting them into the local script to populate values and changing the splats in what's left to @using:parameter_hash.


Private proxy function - good idea or not?
function Private:get-acl {get-acl select | -expand Access}

Added to your profile, changes the way get-acl works from the console, but not from a child scope (called script, invoke-command, etc).

The private scope means you can use the cmdlet name you're proxying in the function script block without needing $ExecutionContext.InvokeCommand.GetCommand('Get-ChildItem', [System.Management.Automation.Command Types]::Cmdlet)

The Private: options hides the function from child scopes, even the function's own scope can't see it so you don't get the recursion loop.
Wait while more posts are being loaded