Skip to content

Commit 4133cc6

Browse files
Merge pull request #12656 from MicrosoftDocs/main
Auto Publish – main to live - 2026-01-13 23:00 UTC
2 parents 95b5072 + 718e06e commit 4133cc6

File tree

18 files changed

+456
-272
lines changed

18 files changed

+456
-272
lines changed

reference/5.1/Microsoft.PowerShell.Core/About/about_Calculated_Properties.md

Lines changed: 10 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
---
22
description: PowerShell provides the ability to dynamically add new properties and alter the formatting of objects output to the pipeline.
33
Locale: en-US
4-
ms.date: 09/03/2024
4+
ms.date: 01/13/2026
55
online version: https://learn.microsoft.com/powershell/module/microsoft.powershell.core/about/about_calculated_properties?view=powershell-5.1&WT.mc_id=ps-gethelp
66
schema: 2.0.0
77
title: about_Calculated_Properties
@@ -16,12 +16,16 @@ the formatting of objects output to the pipeline.
1616
## Long description
1717

1818
Several PowerShell cmdlets transform, group, or process input objects into
19-
output objects using parameters that allow the addition of new properties to
19+
output objects using parameters that allow you to create new properties on
2020
those output objects. You can use these parameters to generate new, calculated
21-
properties on output objects based on the values of input objects. The
22-
calculated property is defined by a [hashtable][03] containing key-value pairs
23-
that specify the name of the new property, an expression to calculate the
24-
value, and optional formatting information.
21+
properties on output objects based on the values of input objects. The input
22+
object can be accessed using the `$_` or `$PSItem` automatic variable within
23+
the `Expression` member a calculated property.
24+
25+
The calculated property is defined as a [hashtable][03] containing key-value
26+
pairs that specify the value of the newly calculated property. Some commands
27+
support other key-value pairs that control how the property is displayed in the
28+
output.
2529

2630
## Supported cmdlets
2731

reference/5.1/Microsoft.PowerShell.Core/About/about_PSItem.md

Lines changed: 61 additions & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
---
22
description: The automatic variable that contains the current object in the pipeline object.
33
Locale: en-US
4-
ms.date: 04/17/2025
4+
ms.date: 01/13/2026
55
online version: https://learn.microsoft.com/powershell/module/microsoft.powershell.core/about/about_psitem?view=powershell-5.1&WT.mc_id=ps-gethelp
66
schema: 2.0.0
77
title: about_PSItem
@@ -14,13 +14,15 @@ The automatic variable that contains the current object in the pipeline object.
1414

1515
## Long description
1616

17-
PowerShell includes the `$PSItem` variable and its alias, `$_`, as
18-
[automatic variables][03] in scriptblocks that process the current object, such
19-
as in the pipeline. This article uses `$PSItem` in the examples, but `$PSItem`
20-
can be replaced with `$_` in every example.
17+
PowerShell includes two [automatic variables][03], `$_` and '$PSItem` that
18+
refer to the current object in the pipeline.
2119

22-
You can use this variable in commands that perform an action on every object in
23-
a pipeline.
20+
`$PSItem` was added to PowerShell in an attempt to provide a clearer meaning to
21+
the variable name. However, in practice, the _dollar sign underscore_ form `$_`
22+
is most commonly used.
23+
24+
While this article uses `$PSItem` in the examples, `$PSItem` can be replaced
25+
with `$_` in every example. `$_` is the preferred usage.
2426

2527
There are a few common use cases for `$PSItem`:
2628

@@ -30,16 +32,16 @@ There are a few common use cases for `$PSItem`:
3032
cmdlet
3133
- In the intrinsic methods **ForEach** and **Where**
3234
- with delay-bind scriptblock parameters
33-
- In a `switch` statement's conditional values and associated scriptblocks
34-
- In the `process` block of a function
35+
- In a `switch` statement's conditional values and associated statements
36+
- In the `process` statement block of a function
3537
- In a `filter` definition
3638
- In the scriptblock of the **ValidateScript** attribute
37-
- In the scriptblock of a `catch` statement
39+
- In the statement block of a `catch`
3840

3941
The rest of this article includes examples of using `$PSItem` for these use
4042
cases.
4143

42-
## ForEach-Object Process
44+
## ForEach-Object Process parameter
4345

4446
The [ForEach-Object][15] cmdlet is designed to operate on objects in the
4547
pipeline, executing the **Process** parameter's scriptblock once for every
@@ -110,7 +112,7 @@ B
110112
In this example, the scriptblock of the **ForEach** method uppercases the
111113
current object. Then the scriptblock of the **Where** method returns only `B`.
112114

113-
## Delay-bind ScriptBlock parameters
115+
## Delay-bind scriptblocks
114116

115117
[Delay-bind scriptblocks][12] let you use `$PSItem` to define parameters for a
116118
pipelined cmdlet before executing it.
@@ -119,7 +121,7 @@ pipelined cmdlet before executing it.
119121
dir config.log | Rename-Item -NewName { "old_$($_.Name)" }
120122
```
121123

122-
## Switch statement ScriptBlocks
124+
## Switch statements
123125

124126
In [switch statements][13], you can use `$PSItem` in both action scriptblocks
125127
and statement condition scriptblocks.
@@ -139,23 +141,23 @@ switch ($numbers) {
139141
3 is odd
140142
```
141143

142-
In this example, the statement condition scriptblock checks whether the current
143-
object is even. If it's even, the associated action scriptblock outputs a
144+
In this example, the condition statement block checks whether the current
145+
object is even. If it's even, the associated action statement block outputs a
144146
message indicating the current object is even.
145147

146-
The action scriptblock for the `default` condition outputs a message indicating
147-
the current object is odd.
148+
The action statement block for the `default` condition outputs a message
149+
indicating the current object is odd.
148150

149-
## Function process blocks
151+
## Function process statement blocks
150152

151153
When you define a [function][09], you can use `$PSItem` in the `process` block
152154
definition but not in the `begin` or `end` block definitions. If you
153155
reference `$PSItem` in the `begin` or `end` blocks, the value is `$null`
154156
because those blocks don't operate on each object in the pipeline.
155157

156-
When you use `$PSItem` in the `process` block definition, the value is the
157-
value is the current object if the function is called in the pipeline and
158-
otherwise `$null`.
158+
When you use `$PSItem` in the `process` statement block definition, the value
159+
is the current object if the function is called in the pipeline and otherwise
160+
`$null`.
159161

160162
```powershell
161163
function Add-One {
@@ -173,9 +175,10 @@ function Add-One {
173175

174176
> [!TIP]
175177
> While you can use `$PSItem` in [advanced functions][08], there's little
176-
> reason to do so. If you intend to receive input from the pipeline,
177-
> it's best to define parameters with one of the `ValueFromPipeline*` arguments
178-
> for the [Parameter][06] attribute.
178+
> reason to do so. If you intend to receive input from the pipeline, it's best
179+
> to define parameters with using either the `ValueFromPipeline` or
180+
> `ValueFromPipelineByPropertyName` arguments in the [Parameter][06]
181+
> attribute.
179182
180183
Using the **Parameter** attribute and cmdlet binding for advanced functions
181184
makes the implementation more explicit and predictable than processing the
@@ -354,23 +357,23 @@ value isn't even.
354357
The `Add-EvenNumber` function adds the valid input numbers and returns the
355358
total.
356359

357-
## The `catch` statement ScriptBlock
360+
## The `catch` statement block
358361

359-
Within a `catch` block, the current error can be accessed using `$PSItem`. The
362+
Within a `catch` statement block, `$PSItem` contains the current error. The
360363
object is of type **ErrorRecord**.
361364

362365
```powershell
363366
try { NonsenseString }
364367
catch {
365368
Write-Host "An error occurred:"
366-
Write-Host $_
369+
Write-Host $PSItem
367370
}
368371
```
369372

370373
Running this script returns the following result:
371374

372375
```Output
373-
An Error occurred:
376+
An error occurred:
374377
The term 'NonsenseString' is not recognized as the name of a cmdlet, function,
375378
script file, or operable program. Check the spelling of the name, or if a path
376379
was included, verify that the path is correct and try again.
@@ -379,6 +382,36 @@ was included, verify that the path is correct and try again.
379382
For more examples, see the _Accessing exception information_ section in
380383
[about_Try_Catch_Finally][14].
381384

385+
## Changing the value of `$PSItem`
386+
387+
You can change the value of `$PSItem` by assigning a new value to it. However,
388+
doing so can change the expected behavior of any code that relies on `$PSItem`.
389+
Consider the following example. Normally, the `switch` statement would process
390+
all values in the array `$names`. Because the value of `$PSItem` is changed
391+
inside the action statement block, the `switch` statement processes only the
392+
first value.
393+
394+
```powershell
395+
$names = 'Alice', 'Charlie'
396+
switch ($names) {
397+
Alice { "$PSItem says 'Hello!'"; $PSItem = 'Bob' }
398+
Bob { "$PSItem says 'Goodbye.'"; $PSItem = 'Charlie'; break }
399+
Charlie { "$PSItem says 'How are you?'" }
400+
}
401+
```
402+
403+
When the `switch` statement evaluates the first value, `Alice`, it matches the
404+
first condition and executes the associated action statement block. Inside that
405+
block, the value of `$PSItem` is changed to `Bob`, which also affects the
406+
evaluation of the `switch` statement.
407+
408+
```Output
409+
Alice says 'Hello!'
410+
Bob says 'Goodbye.'
411+
```
412+
413+
You should avoid changing the value of `$PSItem`.
414+
382415
## See also
383416

384417
- [about_Arrays][01]

reference/5.1/Microsoft.PowerShell.Core/About/about_Trap.md

Lines changed: 25 additions & 26 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
---
22
description: Describes a keyword that handles a terminating error.
33
Locale: en-US
4-
ms.date: 07/05/2024
4+
ms.date: 01/13/2026
55
online version: https://learn.microsoft.com/powershell/module/microsoft.powershell.core/about/about_trap?view=powershell-5.1&WT.mc_id=ps-gethelp
66
schema: 2.0.0
77
title: about_Trap
@@ -28,10 +28,10 @@ following ways:
2828
the default.
2929

3030
> [!NOTE]
31-
> When the terminating error occurs in a subordinate script block, such as
31+
> When the terminating error occurs in a subordinate statement block, such as
3232
> an `if` statement or `foreach` loop, the statements in the `trap` block are
3333
> run and execution continues at the next statement outside the subordinate
34-
> script block.
34+
> block.
3535
3636
- Display the error and abort execution of the script or function containing
3737
the `trap` using `break` in the `trap` statement.
@@ -42,7 +42,7 @@ following ways:
4242
The statement list of the `trap` can include multiple conditions or function
4343
calls. A `trap` can write logs, test conditions, or even run another program.
4444

45-
### Syntax
45+
## Syntax
4646

4747
The `trap` statement has the following syntax:
4848

@@ -59,7 +59,7 @@ types of errors the `trap` catches.
5959
A script or command can have multiple `trap` statements. `trap` statements can
6060
appear anywhere in the script or command.
6161

62-
### Trapping all terminating errors
62+
## Trapping all terminating errors
6363

6464
When a terminating error occurs that isn't handled in another way in a script
6565
or command, PowerShell checks for a `trap` statement that handles the error. If
@@ -103,7 +103,7 @@ At line:3 char:5
103103
```
104104

105105
The following example includes a `trap` statement that displays the error by
106-
using the `$_` automatic variable:
106+
using the `$_` or `$PSItem` automatic variable:
107107

108108
```powershell
109109
function TrapTest {
@@ -134,17 +134,16 @@ At line:3 char:5
134134
```
135135

136136
> [!IMPORTANT]
137-
> `trap` statements may be defined anywhere within a given script block, but
138-
> always apply to all statements in that script block. At runtime, `trap`
137+
> `trap` statements can be defined anywhere within a given scriptblock, but
138+
> always apply to all statements in that scriptblock. At runtime, `trap`
139139
> statements in a block are defined before any other statements are executed.
140-
> In JavaScript, this is known as
141-
> [hoisting](https://wikipedia.org/wiki/JavaScript_syntax#hoisting). This means
142-
> that `trap` statements apply to all statements in that block even if
140+
> In other languages, such as JavaScript, this is known as [hoisting][06]. This
141+
> means that `trap` statements apply to all statements in that block even if
143142
> execution hasn't advanced past the point at which they're defined. For
144143
> example, defining a `trap` at the end of a script and throwing an error in
145144
> the first statement still triggers that `trap`.
146145
147-
### Trapping specific errors
146+
## Trapping specific errors
148147

149148
A script or command can have multiple `trap` statements. A `trap` can be
150149
defined to handle specific errors.
@@ -201,7 +200,7 @@ System.Management.Automation.CommandNotFoundException
201200
You can have more than one `trap` statement in a script. Only one `trap`
202201
statement can trap each error type. When a terminating error occurs, PowerShell
203202
searches for the `trap` with the most specific match, starting in the current
204-
script block of execution.
203+
scriptblock of execution.
205204

206205
The following script example contains an error. The script includes a general
207206
`trap` statement that traps any terminating error and a specific `trap`
@@ -262,13 +261,13 @@ The attempt to divide by zero doesn't create a **CommandNotFoundException**
262261
error. The other `trap` statement, which traps any terminating error, traps the
263262
divide by zero error.
264263

265-
### Trapping errors in a script block
264+
## Trapping errors in a scriptblock
266265

267266
By default, when a terminating error is thrown, execution transfers to the trap
268267
statement. After the `trap` block is run, control returns to the next statement
269268
block after the location of the error.
270269

271-
For example, when a terminating error occurs in an `foreach` statement, the
270+
For example, when a terminating error occurs in a `foreach` statement, the
272271
`trap` statement is run and execution continues at the next statement after the
273272
`foreach` block, not within the `foreach` block.
274273

@@ -302,16 +301,16 @@ after loop
302301

303302
In the output, you can see the loops continue until the last iteration. When
304303
the script tries to divide 1 by 0, PowerShell throws a terminating error. The
305-
script skips the rest of the `foreach` script block, runs the `try` statement,
306-
and continues after the `foreach` script block.
304+
script skips the rest of the `foreach` statement, runs the `try` statement,
305+
and continues after the `foreach` statement.
307306

308-
### Trapping errors and scope
307+
## Trapping errors and scope
309308

310-
If a terminating error occurs in the same script block as the `trap` statement,
309+
If a terminating error occurs in the same scriptblock as the `trap` statement,
311310
PowerShell runs the list of statements defined by the `trap`. Execution
312311
continues at the statement after the error. If the `trap` statement is in a
313-
different script block from the error, execution continues at the next
314-
statement that's in the same script block as the `trap` statement.
312+
different scriptblock from the error, execution continues at the next
313+
statement that's in the same scriptblock as the `trap` statement.
315314

316315
For example, if an error occurs in a function, and the `trap` statement is in
317316
the function, the script continues at the next statement. The following script
@@ -387,7 +386,7 @@ back into the function after the `trap` statement runs.
387386

388387
> [!CAUTION]
389388
> When multiple traps are defined for the same error condition, the first
390-
> `trap` defined lexically (highest in the script block) is used.
389+
> `trap` defined lexically (highest in the scriptblock) is used.
391390
392391
In the following example, only the `trap` with `whoops 1` runs.
393392

@@ -402,7 +401,7 @@ trap { 'whoops 2'; continue }
402401
> statement inside a function or dot sourced script, when the function or dot
403402
> sourced script exits, all `trap` statements inside are removed.
404403
405-
### Using the break and continue keywords
404+
## Using the break and continue keywords
406405

407406
You can use the `break` and `continue` keywords in a `trap` statement to
408407
determine whether a script or command continues to run after a terminating
@@ -481,11 +480,11 @@ statement runs. No error is written to the error stream.
481480
## Notes
482481

483482
`trap` statements provide a way to ensure all terminating errors within a
484-
script block are handled. For more finer-grained error handling, use
485-
`try`/`catch` blocks where traps are defined using `catch` statements. The
483+
scriptblock are handled. For more fine-grained error handling, use
484+
`try/catch` blocks where traps are defined using `catch` statements. The
486485
`catch` statements only apply to the code inside the associated `try`
487486
statement. For more information, see
488-
[about_Try_Catch_Finally](about_Try_Catch_Finally.md).
487+
[about_Try_Catch_Finally][05].
489488

490489
## See also
491490

reference/5.1/Microsoft.PowerShell.Core/About/about_Try_Catch_Finally.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
---
22
description: Describes how to use the `try`, `catch`, and `finally` blocks to handle terminating errors.
33
Locale: en-US
4-
ms.date: 05/14/2025
4+
ms.date: 01/13/2026
55
online version: https://learn.microsoft.com/powershell/module/microsoft.powershell.core/about/about_try_catch_finally?view=powershell-5.1&WT.mc_id=ps-gethelp
66
schema: 2.0.0
77
title: about_Try_Catch_Finally
@@ -189,8 +189,8 @@ any parent scope has a matching `catch` block.
189189

190190
## Accessing exception information
191191

192-
Within a `catch` block, the current error can be accessed using `$_`, which is
193-
also known as `$PSItem`. The object is of type **ErrorRecord**.
192+
Within a `catch` block, the current error can be accessed using the `$_` or
193+
`$PSItem` automatic variable. The object is of type **ErrorRecord**.
194194

195195
```powershell
196196
try { NonsenseString }

0 commit comments

Comments
 (0)