Redirecting to a variable should be possible

[JamesWTruher]

PR Summary

There are a number of situations where it would be very convenient to redirect data to a variable using the variable:name syntax. This PR provides this behavior by inspecting the target of the redirection and if it uses the variable provider will call Set-Variable rather than Out-File.

With this PR the following scenarios are possible:

PS /> .{                                                                                   
>> "Output 1"
>> Write-Warning "Warning, Warning!"
>> "Output 2"
>> } 3> variable:warns
Output 1
Output 2
PS /> $warns
WARNING: Warning, Warning!
PS /> 

This could prove very helpful to some logging scenarios as well.

S /> .{                                                                                   
>> "Output 1"
>> Write-Warning "This is a warning"
>> "Output 2"
>> Write-Debug -Debug "and a debug message"
>> "Output 3"
>> } *> variable:kitchenSync
PS /> $kitchenSync
Output 1
WARNING: This is a warning
Output 2
DEBUG: and a debug message
Output 3

Append is also supported via >>

PS /> .{ "output 1" } *>variable:outputs                                                   
PS /> .{ "output 2" } *>>variable:outputs
PS /> .{ write-warning warn! } *>>variable:outputs
PS /> .{ "output 3" } *>>variable:outputs         
PS /> $outputs                   
output 1
output 2
WARNING: warn!
output 3

and redirecting multiple streams to multiple targets, based on the stream number:

PS /> .{
>> "output 1"
>> write-warning "Warning!"
>> "output 2"
>> write-debug -debug "debug here"
>> "output 3"
>> write-information Info
>> "output 4"
>> write-error "That's bad!"
>> Write-Verbose -Verbose "and verbose"
>> "all done"
>> } > variable:outputStream 2>variable:errorStream 3>variable:warningStream 4>variable:verboseStream 5>variable:debugStream 6>variable:InfoStream
PS /> $outputStream
output 1
output 2
output 3
output 4
all done
PS /> $errorStream 
Write-Error: That's bad!
PS /> $warningStream
WARNING: Warning!
PS /> $verboseStream                   
VERBOSE: and verbose
PS /> $debugStream  
DEBUG: debug here
PS /> $InfoStream 
Info

Lastly, object-ness is preserved:

PS /> .{                                 
>> "output"
>> write-error "bad"
>> write-warning "warn"
>> write-verbose -verbose "verbose"
>> write-debug -debug debug
>> } *>variable:all
PS /> $all | %{$_.gettype()}

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     String                                   System.Object
True     False    ErrorRecord                              System.Object
True     False    WarningRecord                            System.Management.Automation.InformationalRecord
True     False    VerboseRecord                            System.Management.Automation.InformationalRecord
True     False    DebugRecord                              System.Management.Automation.InformationalRecord

This is not to say that redirection to a variable should take the place of assignment, but it does enable some new scenarios.

the current behavior when redirecting to a variable is an error (because redirection is implemented via Out-File):

PS /> "sldfkj" >variable:no          
Out-File: Cannot open file because the current provider (Microsoft.PowerShell.Core\Variable) cannot open a file.

PR Context

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s): PSRedirectToVariable
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and opened an issue in the relevant tool repository. This may include:
    • Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode
      (which runs in a different PS Host).
      • Issue filed:
    • Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
      • Issue filed:
    • Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
      • Issue filed:
    • Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).
      • Issue filed:

[SeeminglyScience]

Some very minor style nits, other than that looks great! Very excited for this change ❤️

[pull-request-quantifier-deprecated]

This PR has 183 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

---

Quantification details

Label      : Medium
Size       : +173 -10
Percentile : 56.6%

Total files changed: 7

Change summary by file extension:
.cs : +56 -9
.resx : +3 -0
.ps1 : +114 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

• Fast and predictable releases to production:
  • Optimal size changes are more likely to be reviewed faster with fewer
    iterations.
  • Similarity in low PR complexity drives similar review times.
• Review quality is likely higher as complexity is lower:
  • Bugs are more likely to be detected.
  • Code inconsistencies are more likely to be detected.
• Knowledge sharing is improved within the participants:
  • Small portions can be assimilated better.
• Better engineering practices are exercised:
  • Solving big problems by dividing them in well contained, smaller problems.
  • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

• Use the PullRequestQuantifier to quantify your PR accurately
  • Create a context profile for your repo using the context generator
  • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
  • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
  • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
• Change your engineering behaviors
  • For PRs that fall outside of the desired spectrum, review the details and check if:
    • Your PR could be split in smaller, self-contained PRs instead
    • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

• One line was added: +1 -0
• One line was deleted: +0 -1
• One line was modified: +1 -1 (git diff doesn't know about modified, it will
  interpret that line like one addition plus one deletion)
• Change percentiles: Change characteristics (addition, deletion, modification)
  of this PR in relation to all other PRs within the repository.

---

Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

[pull-request-quantifier-deprecated]

This PR has 183 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

---

Quantification details

Label      : Medium
Size       : +173 -10
Percentile : 56.6%

Total files changed: 7

Change summary by file extension:
.cs : +56 -9
.resx : +3 -0
.ps1 : +114 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

• Fast and predictable releases to production:
  • Optimal size changes are more likely to be reviewed faster with fewer
    iterations.
  • Similarity in low PR complexity drives similar review times.
• Review quality is likely higher as complexity is lower:
  • Bugs are more likely to be detected.
  • Code inconsistencies are more likely to be detected.
• Knowledge sharing is improved within the participants:
  • Small portions can be assimilated better.
• Better engineering practices are exercised:
  • Solving big problems by dividing them in well contained, smaller problems.
  • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

• Use the PullRequestQuantifier to quantify your PR accurately
  • Create a context profile for your repo using the context generator
  • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
  • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
  • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
• Change your engineering behaviors
  • For PRs that fall outside of the desired spectrum, review the details and check if:
    • Your PR could be split in smaller, self-contained PRs instead
    • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

• One line was added: +1 -0
• One line was deleted: +0 -1
• One line was modified: +1 -1 (git diff doesn't know about modified, it will
  interpret that line like one addition plus one deletion)
• Change percentiles: Change characteristics (addition, deletion, modification)
  of this PR in relation to all other PRs within the repository.

---

Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

[pull-request-quantifier-deprecated]

This PR has 186 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

---

Quantification details

Label      : Medium
Size       : +174 -12
Percentile : 57.2%

Total files changed: 7

Change summary by file extension:
.cs : +57 -11
.resx : +3 -0
.ps1 : +114 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

• Fast and predictable releases to production:
  • Optimal size changes are more likely to be reviewed faster with fewer
    iterations.
  • Similarity in low PR complexity drives similar review times.
• Review quality is likely higher as complexity is lower:
  • Bugs are more likely to be detected.
  • Code inconsistencies are more likely to be detected.
• Knowledge sharing is improved within the participants:
  • Small portions can be assimilated better.
• Better engineering practices are exercised:
  • Solving big problems by dividing them in well contained, smaller problems.
  • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

• Use the PullRequestQuantifier to quantify your PR accurately
  • Create a context profile for your repo using the context generator
  • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
  • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
  • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
• Change your engineering behaviors
  • For PRs that fall outside of the desired spectrum, review the details and check if:
    • Your PR could be split in smaller, self-contained PRs instead
    • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

• One line was added: +1 -0
• One line was deleted: +0 -1
• One line was modified: +1 -1 (git diff doesn't know about modified, it will
  interpret that line like one addition plus one deletion)
• Change percentiles: Change characteristics (addition, deletion, modification)
  of this PR in relation to all other PRs within the repository.

---

Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.

[SteveL-MSFT]

Just a note and not something you need to change, but it seems in the future, it would make more sense to have Out-Provider and have the provider subsystem determine which provider receives it rather than hardcoding to specific cases here

[JamesWTruher]

I did think about that when I put this together and thought that the scenarios for redirection to something other than filesystem or variable were pretty limited, so I took this approach.

[SteveL-MSFT]

I agree that a smaller change now makes sense. Created #23794 to capture this.

[microsoft-github-policy-service]

📣 Hey @JamesWTruher, how did we do? We would love to hear your feedback with the link below! 🗣️

🔗 https://aka.ms/PSRepoFeedback

Microsoft Forms