Fix $args automatic variable case

[surfingoldelephant]

PR Summary

This PR fixes incorrect automatic variable casing used throughout the documentation. E.g., $Args (incorrect) -> $args (correct).

In this PR:

• $args

Context

This series of PRs ensures the correct case is consistently used for each individual automatic variable, as documented in about_Automatic_Variables and verified by tab completion.

Changes in scope:

• Variables with a $ or @ sigil.
• Variables referenced by name without a sigil.

Out of scope:

• Preference variables (separate PRs to follow).
• Misuse of an automatic variable (e.g., naming a function parameter as $Input).
• Reference to the variable's value (e.g., false/False/FALSE when referring to the value of $false).

PR Checklist

• Descriptive Title: This PR's title is a synopsis of the changes it proposes.
• Summary: This PR's summary describes the scope and intent of the change.
• Contributor's Guide: I have read the contributors guide.
• Style: This PR adheres to the style guide.

[learn-build-service-prod]

Learn Build status updates of commit c8d8603:

✅ Validation status: passed

File	Status	Preview URL	Details
reference/5.1/Microsoft.PowerShell.Core/About/about_Debuggers.md	✅Succeeded	View (powershell-5.1)
reference/5.1/Microsoft.PowerShell.Core/About/about_Functions_Advanced_Parameters.md	✅Succeeded	View (powershell-5.1)
reference/5.1/Microsoft.PowerShell.Core/About/about_Functions_CmdletBindingAttribute.md	✅Succeeded	View (powershell-5.1)
reference/5.1/Microsoft.PowerShell.Core/About/about_Functions.md	✅Succeeded	View (powershell-5.1)
reference/5.1/Microsoft.PowerShell.Core/About/about_Splatting.md	✅Succeeded	View (powershell-5.1)
reference/5.1/Microsoft.PowerShell.Management/Register-WmiEvent.md	✅Succeeded	View (powershell-5.1)
reference/5.1/Microsoft.PowerShell.Utility/Get-Event.md	✅Succeeded	View (powershell-5.1)
reference/5.1/Microsoft.PowerShell.Utility/New-Event.md	✅Succeeded	View (powershell-5.1)
reference/5.1/Microsoft.PowerShell.Utility/Register-EngineEvent.md	✅Succeeded	View (powershell-5.1)
reference/5.1/Microsoft.PowerShell.Utility/Register-ObjectEvent.md	✅Succeeded	View (powershell-5.1)
reference/7.4/Microsoft.PowerShell.Core/About/about_Debuggers.md	✅Succeeded	View (powershell-7.4)
reference/7.4/Microsoft.PowerShell.Core/About/about_Functions_Advanced_Parameters.md	✅Succeeded	View (powershell-7.4)
reference/7.4/Microsoft.PowerShell.Core/About/about_Functions_CmdletBindingAttribute.md	✅Succeeded	View (powershell-7.4)
reference/7.4/Microsoft.PowerShell.Core/About/about_Functions.md	✅Succeeded	View (powershell-7.4)
reference/7.4/Microsoft.PowerShell.Core/About/about_Splatting.md	✅Succeeded	View (powershell-7.4)
reference/7.4/Microsoft.PowerShell.Utility/Get-Event.md	✅Succeeded	View (powershell-7.4)
reference/7.4/Microsoft.PowerShell.Utility/New-Event.md	✅Succeeded	View (powershell-7.4)
reference/7.4/Microsoft.PowerShell.Utility/Register-EngineEvent.md	✅Succeeded	View (powershell-7.4)
reference/7.4/Microsoft.PowerShell.Utility/Register-ObjectEvent.md	✅Succeeded	View (powershell-7.4)
reference/7.5/Microsoft.PowerShell.Core/About/about_Debuggers.md	✅Succeeded	View (powershell-7.5)
reference/7.5/Microsoft.PowerShell.Core/About/about_Functions_Advanced_Parameters.md	✅Succeeded	View (powershell-7.5)
reference/7.5/Microsoft.PowerShell.Core/About/about_Functions_CmdletBindingAttribute.md	✅Succeeded	View (powershell-7.5)
reference/7.5/Microsoft.PowerShell.Core/About/about_Functions.md	✅Succeeded	View (powershell-7.5)
reference/7.5/Microsoft.PowerShell.Core/About/about_Splatting.md	✅Succeeded	View (powershell-7.5)
reference/7.5/Microsoft.PowerShell.Utility/Get-Event.md	✅Succeeded	View (powershell-7.5)

This comment lists only the first 25 files in the pull request.
For more details, please refer to the build report.

For any questions, please:

• Try searching the learn.microsoft.com contributor guides
• Post your question in the Learn support channel

[github-actions]

Expectations

Thanks for your submission! Here's a quick note to provide you with some context for what to expect from the docs team and the process now that you've submitted a PR. Even if you've contributed to this repo before, we strongly suggest reading this information; it might have changed since you last read it.

To see our process for reviewing PRs, please read our editor's checklist and process for managing pull requests in particular. Below is a brief, high-level summary of what to expect, but our contributor guide has expanded details.

The docs team begins to review your PR if you request them to or if your PR meets these conditions:

• It is not a draft PR.
• It does not have a WIP prefix in the title.
• It passes validation and build steps.
• It does not have any merge conflicts.
• You have checked every box in the PR Checklist, indicating you have completed all required steps and marked your PR as Ready to Merge.

You can always request a review at any stage in your authoring process, the docs team is here to help! You do not need to submit a fully polished and finished draft; the docs team can help you get content ready for merge.

While reviewing your PR, the docs team may make suggestions, write comments, and ask questions. When all requirements are satisfied, the docs team marks your PR as Approved and merges it. Once your PR is merged, it is included the next time the documentation is published. For this project, the documentation is published daily at 3 p.m. Pacific Standard Time (PST).

[surfingoldelephant]

@sdwheeler I have 25 commits in total, one for each automatic variable that requires a fix. The number of files touched per commit ranges from 1-153.

I don't want to overwhelm a single PR review, nor generate a large number of conflicts due to the number of touched files.

If I submit one PR, wait for it to be reviewed/merged and then submit another based on updated main, would that OK?

E.g., the $args commit touches 38 files, which is substantial, so this PR has just one commit. On the other-hand, $Error, $Event and $ExecutionContext touch a combined 22 files, so those three commits would be grouped into the same PR.

[sdwheeler]

I have 25 commits in total, one for each automatic variable that requires a fix. The number of files touched per commit ranges from 1-153.

@surfingoldelephant Limit the PRs to 30-40 files. It's best to include the same files for all versions in a single PR, like you did in this PR.

[surfingoldelephant]

Limit the PRs to 30-40 files.

Just to clarify, it was simpler/less error-prone to fix one variable at a time, committing after each fixed variable. So the changes are on a per-variable basis, not file. E.g.,

• $args commit - 38 files modified
• $Error commit - 10 files modified
• $true commit - 153 files modified

There are three variables that exceed the 40 file limit: $false (92 files), $PSHOME (49 files) and $true (153 files). Would it be OK if we make an exception for those? I feel like splitting, e.g., $true into four separate PRs will complicate things considerably.

[sdwheeler]

Just to clarify, it was simpler/less error-prone to fix one variable at a time, committing after each fixed variable. So the changes are on a per-variable basis

Oh, I understand now. In my mind, the changes are small and related. I would rather get a PR that contains changes for all variables, but limit the file count and include all affected versions. For example, fix all the variables in 10 files across 4 versions in 1 PR.

[surfingoldelephant]

For example, fix all the variables in 10 files across 4 versions in 1 PR.

I initially considered this, but felt this approach would've made the fix considerably more complex.

I would rather get a PR that contains changes for all variables, but limit the file count and include all affected versions.

Understood. I'll be sure to keep this in mind in the future.

For now, I can't see a clean way of transforming what I have into PRs that satisfy this. I've fixed all variables across all files - just not in the manner you're looking for PR-wise.

I'll submit one more PR with what I have and let you decide how you want to proceed.