Powershell: Use a variable to reference a property of $_ in a script block

Question

$var =@(  @{id="1"; name="abc"; age="1"; },
          @{id="2"; name="def"; age="2"; } );
$properties = @("ID","Name","Age") ;
$format = @();
foreach ($p  in $properties)
{
    $format += @{label=$p ; Expression = {$_.$p}} #$_.$p is not working!
}
$var |% { [PSCustomObject]$_  } | ft $format

In the above example, I want to access each object's property through a variable name. But it cannot work as expected. So in my case, how to make

Expression = {$_.$p}

working?

Answer 1

^{The OP's code and this answer use PSv3+ syntax. Casting a hashtable to [pscustomobject] is not supported in PSv2, but you can replace [pscustomobject] $_ with New-Object PSCustomObject -Property $_.}

As in many cases in the past, PetSerAl has provided the answer in terse (but very helpful) comments on the question; let me elaborate:

Your problem is not that you're using a variable ($p) to access a property per se, which does work (e.g., $p = 'Year'; Get-Date | % { $_.$p }).

Instead, the problem is that $p in script block { $_.$p } isn't evaluated until later, in the context of the Format-Table call, which means that the same, fixed value is used for all input objects - namely the value of $p at that point (which happens to be the last value that was assigned to $p in the foreach loop).

The cleanest and most generic solution is to call .GetNewClosure() on the script block to bind $p in the script block to the then-current, loop-iteration-specific value.

$format += @{ Label = $p; Expression = { $_.$p }.GetNewClosure() }

From the docs (emphasis added; update: the quoted passage has since been removed, but still applies):

In this case, the new script block is closed over the local variables in the scope that the closure is defined in. In other words, the current values of the local variables are captured and enclosed inside the script block that is bound to the module.

Note that automatic variable $_ is undefined inside the foreach loop (PowerShell defines it only in certain contexts as the input object at hand, such as in script blocks passed to cmdlets in a pipeline), so it remains unbound, as desired.

Caveats:

• While .GetNewClosure() as used above is convenient, it has the inefficiency drawback of invariably capturing all local variables, not just the one(s) needed; also, the returned script block runs in a dynamic (in-memory) module created for the occasion.

• A more efficient alternative that avoids this problem - and notably also avoids a bug (as of Windows PowerShell v5.1.14393.693 and PowerShell Core v6.0.0-alpha.15) in which the closure over the local variables can break, namely when the enclosing script / function has a parameter with validation attributes such as [ValidateNotNull()] and that parameter is not bound (no value is passed)^[1] - is the following, significantly more complex expression ^{Tip of the hat again to PetSerAl, and Burt_Harris's answer here} :

    $format += @{ Label = $p; Expression = & { $p = $p; { $_.$p }.GetNewClosure() } }
  

  • & { ... } creates a child scope with its own local variables.
  • $p = $p then creates a local $p variable from its inherited value.
    To generalize this approach, you must include such a statement for each variable referenced in the script block.
  • { $_.$p }.GetNewClosure() then outputs a script block that closes over the child scope's local variables (just $p in this case).
  • The bug has been reported as an issue in the PowerShell Core GitHub repository and has since been fixed - it's unclear to me in what versions the fix will ship.

• For simple cases, mjolinor's answer may do: it indirectly creates a script block via an expanded string that incorporates the then-current $p value literally, but note that the approach is tricky to generalize, because just stringifying a variable value doesn't generally guarantee that it works as part of PowerShell source code (which the expanded string must evaluate to in order to be converted to a script block).

To put it all together:

# Sample array of hashtables.
# Each hashtable will be converted to a custom object so that it can
# be used with Format-Table.
$var = @(  
          @{id="1"; name="abc"; age="3" }
          @{id="2"; name="def"; age="4" }
       )

# The array of properties to output, which also serve as
# the case-exact column headers.
$properties = @("ID", "Name", "Age")

# Construct the array of calculated properties to use with Format-Table: 
# an array of output-column-defining hashtables.
$format = @()
foreach ($p in $properties)
{
    # IMPORTANT: Call .GetNewClosure() on the script block
    #            to capture the current value of $p.
    $format += @{ Label = $p; Expression = { $_.$p }.GetNewClosure() }
    # OR: For efficiency and full robustness (see above):
    # $format += @{ Label = $p; Expression = & { $p = $p; { $_.$p }.GetNewClosure() } }
}

$var | ForEach-Object { [pscustomobject] $_ } | Format-Table $format

This yields:

ID Name Age
-- ---- ---
1  abc  3  
2  def  4  

as desired: the output columns use the column labels specified in $properties while containing the correct values.

^{Note how I've removed unnecessary ; instances and replaced built-in aliases % and ft with the underlying cmdlet names for clarity. I've also assigned distinct age values to better demonstrate that the output is correct.}

---

Simpler solution, in this specific case:

To reference a property value as-is, without transformation, it is sufficient to use the name of the property as the Expression entry in the calculated property (column-formatting hashtable). In other words: you do not need a [scriptblock] instance containing an expression in this case ({ ... }), only a [string] value containing the property name.

Therefore, the following would have worked too:

# Use the property *name* as the 'Expression' entry's value.
$format += @{ Label = $p; Expression = $p }

Note that this approach happens to avoid the original problem, because $p is evaluated at the time of assignment, so the loop-iteration-specific values are captured.

---

^{[1] To reproduce: function foo { param([ValidateNotNull()] $bar) {}.GetNewClosure() }; foo fails when .GetNewClosure() is called, with error Exception calling "GetNewClosure" with "0" argument(s): "The attribute cannot be added because variable bar with value would no longer be valid."
That is, an attempt is made to include the unbound -bar parameter value - the $bar variable - in the closure, which apparently then defaults to $null, which violates its validation attribute.
Passing a valid -bar value makes the problem go away; e.g., foo -bar ''.
The rationale for considering this a bug: If the function itself treats $bar in the absence of a -bar parameter value as nonexistent, so should .GetNewClosure().}