I had this in a script which I believe was working well, but appears to have stopped working:

$testList = @("object 1","object 2","object 3","object 4","object 5")
$counter = 0
$maxSize = 2
$groupedList = $testList | Group-Object { [math]::Floor($counter   / $maxSize) }
$groupedList
$groupedList | Measure-Object

Previously Measure-Object would have given me a Count of 3, but now I receive a count of 1.

Why is this no longer working? Is the counter integer not being incremented within the Group-Object command anymore?

CodePudding user response：

I don't think your command ever worked as intended (see the bottom section for details).

Replace:

{ [math]::Floor($counter   / $maxSize) }

with:

{ [math]::Floor((Get-Variable -Scope 1 counter).Value   / $maxSize) }

in order to ensure that it is the caller's $counter variable that is updated across invocations of the script block.

Note:

• $script:counter works too, but only if the calling scope is a script's top-level scope.

• Get-Variable -Scope 1 counter explicitly targets the parent scope's definition of $counter, which is the caller's; for brevity you could omit -Scope 1, because by default a variable in the closest ancestral scope is returned.

• Santiago Squarzon suggests another option:

  • You can define your $counter variable as a reference-type object with a .Value property rather than as an integer, in the simplest form as a hashtable:

    $counter = @{ Value = 0 }
    

  • By virtue of $counter now containing an object reference, the child scope in the script block sees the very same object when querying the value of the parent scope's $counter variable, and can update its .Value property:

    { [math]::Floor($counter.Value   / $maxSize) }
    

The problem is that the script block passed to the (positionally) implied -Property parameter of Group-Object runs in a child scope, so that $counter implicitly creates a block-local variable on every invocation:

• That is, $counter does not act on the existing variable in the parent scope; it implicitly creates a scope-local copy of the $counter variable (with the caller's current value), and is applied to it.

  • This perhaps surprising behavior - a local variable implicitly getting created when (ostensibly) assigning to a variable that exists in an ancestral scope - is discussed in detail in this answer.

  • On a related note, it may be surprising that such a script block (which includes calculated properties in general) runs in a child scope rather than directly in the caller's to begin with - see GitHub issue #7157

• Since your is a post-increment, it is the original 0 value (copied from the parent-scope variable) that acts as the LHS operand to the division operation /.

• On exiting the script block, the local $counter variable goes out of scope, and the next invocation starts from scratch.

Thus, in effect, the script block's return value is a fixed 0, so you'll only ever get one group.

Alternatives to using Group-Object for "chunking":

Your use of Group-Object to achieve "chunking" (batching, partitioning, i.e. splitting the input into arrays of fixed size) is elegant, but ultimately inefficient, and it isn't a streaming solution, because all input must be collected up front (neither aspect may matter in a given situation).

• It would be great if Select-Object directly supported such a feature, which is what GitHub issue #8270 proposes, in the form of a -ReadCount parameter:

  # WISHFUL THINKING
  PS> 1..5 | Select-Object -ReadCount 2 | ForEach-Object { "$_" }
  1 2
  3 4
  5
  

• This answer provides a custom function, Select-Chunk, which implements this functionality:

  # Assumes function Select-Chunk from the linked answer is defined.
  PS> 1..5 | Select-Chunk -ReadCount 2 | ForEach-Object { "$_" }
  1 2
  3 4
  5