Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Receive-RSJob does not respect common *Variable and *Action parameters #146

Open
slickmonkey opened this issue May 4, 2017 · 3 comments
Labels

Comments

@slickmonkey
Copy link

Do you want to request a feature or report a bug?
Bug
What is the current behavior?
I would expect that Receive-RSJob with the proper -*Action and -*Variable parameters in place would be SILENT, especially if pipeline is further directed to Out-Null, but this is not the case. Because this still forcibly output they pollute the output of the script running them. It should be possible to run this QUIETLY, but
InformationVariable / WarningVariable / ErrorVariable / InformationAction / WarningAction / ErrorAction seem to have no effect.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

  1. Run a job
  2. Invoke Receive-RSJob with -*Variable and -*Action parameters in place.
  3. Note that:
    a) most *Variable parameters are not respected and output variables are not assigned content
    b) *Action parameters are not respected and content is output according to behavior variables outside of Receive-RSJob

What is the expected behavior?
If I simply want to use ReceiveRSJob to mark input job(s) with the HasMoreData == False (to know that their results have been processed), I should be able to:
$null = $completedJobs | Receive-RSJob -OutVariable null -InformationVariable null -WarningVariable null -ErrorVariable null -InformationAction SilentlyContinue -WarningAction SilentlyContinue -ErrorAction SilentlyContinue | Out-Null
...and would expect that there is NO further output to the host, error stream, etc. etc., because _everything is redirected to the null var or Out-Null, but this is not the current outcome. I still get all the error, warning, etc. stream output to the host.

Which versions of Powershell and which OS are affected by this issue? Did this work in previous versions of our scripts?

PS C:\Users\me> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      5.1.14393.1066
PSEdition                      Desktop                                                              
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}                                                              
BuildVersion                   10.0.14393.1066                                                              
CLRVersion                     4.0.30319.42000                                                              
WSManStackVersion              3.0                                                              
PSRemotingProtocolVersion      2.3                                                              
SerializationVersion           1.1.0.1

PS C:\Users\me> Get-Module PoshRSJob | Select-Object -Property Name,Version

Name      Version
----      -------
PoshRSJob 1.7.3.9

Please provide a code example showing the issue, if applicable:

PS C:\Users\me> $param1 = "First Parameter";
$param2 = "Second Parameter";
$scriptTemplate = @'
[CmdletBinding()]
Param (
    [object] $p1,
    [string] $p2
)
$VerbosePreference = "Continue"
$DebugPreference = "Continue"

Write-Output "[STARTING UP]"
Write-Output "Piped object: $_";
Write-Output "Param1: $p1";
Write-Output "Param2: $p2";

Start-Sleep -Seconds 1

Write-Verbose "Some verbose output";

Write-Debug "Debug output";

Write-Information "Extraneous Informational output..."
Write-Warning "Dave -- I can feel my mind going..."
Write-Error "Milk's going bad... there it goes..."

Write-Output "[SHUTTING DOWN]"
'@
$scriptBlock = [System.Management.Automation.ScriptBlock]::Create($scriptTemplate);
Start-RSJob -ScriptBlock $scriptBlock -ArgumentList $param1,$param2 | Out-Null
$jobs = Get-RSJob | Wait-RSJob

Write-Host "---- RECEIVING CONTENT NOT-SO-SILENTLY ----"
$jobs | Receive-RSJob -OutVariable MyOut -InformationVariable MyInfo -WarningVariable MyWarnings -ErrorVariable MyErrors -InformationAction SilentlyContinue -WarningAction SilentlyContinue -ErrorAction SilentlyContinue | Out-Null
Write-Host "---- *VARIABLE ASSIGNMENTS -- MOST BEING LEFT UNASSIGNED ----"

Write-Host "MyOut: $MyOut"
Write-Host "MyInfo: $MyInfo"
Write-Host "MyWarnings: $MyWarnings"
Write-Host "MyErrors: $MyErrors"

Write-Host "---- CLEANING UP ----"
$jobs | Remove-RSJob

---- RECEIVING CONTENT NOT-SO-SILENTLY ----
VERBOSE: Some verbose output
WARNING: Dave -- I can feel my mind going...
Milk's going bad... there it goes...
DEBUG: Debug output
---- *VARIABLE ASSIGNMENTS -- MOST BEING LEFT UNASSIGNED ----
MyOut: [STARTING UP] Piped object:  Param1: First Parameter Param2: Second Parameter [SHUTTING DOWN]
MyInfo: 
MyWarnings: 
MyErrors: 
---- CLEANING UP ----

PS C:\Users\me> 
@proxb proxb added the bug label May 5, 2017
@slickmonkey
Copy link
Author

slickmonkey commented May 5, 2017

Note: I've worked around this problem locally by updating WriteStream.ps1 to better understand the current preference settings (assigned by the *-ActionPreference switches). This is a hack which needs to be properly fixed in PoshRSJob, but at least I can make Receive-RsJob stop polluting the output for now. Note that I started to add handling of the Information stream as well, but this requires more work in the PoshRSJob.psm1 class declarations, etc. etc. to fully support the stream, so it is actually commented out in the appropriate place here. (Updated) code for WriteStream.ps1 is as follows:

Function WriteStream {
    [CmdletBinding()]
    Param (
        [Parameter(ValueFromPipeline=$true)]
        [Object]$IndividualJob
    )
    Begin {
        $Streams = "Verbose","Information","Warning","Error","Output","Debug"
    }

    Process {
        ForEach ($Stream in $Streams)
        {
            $ignored = Switch ($Stream) {
                "Verbose"     { if ($VerbosePreference     -in @('SilentlyContinue','Ignore')) { $true } else { $false } }
                "Debug"       { if ($DebugPreference       -in @('SilentlyContinue','Ignore')) { $true } else { $false } }
                "Information" { if ($InformationPreference -in @('SilentlyContinue','Ignore')) { $true } else { $false } }
                "Warning"     { if ($WarningPreference     -in @('SilentlyContinue','Ignore')) { $true } else { $false } }
                "Error"       { if ($ErrorActionPreference -in @('SilentlyContinue','Ignore')) { $true } else { $false } }
                "Output"      { $false }
            }
                
            If (($IndividualJob.$Stream) -and -not $ignored)
            {
                Switch ($Stream) {
                    "Verbose"     { $IndividualJob | Select-Object -ExpandProperty Verbose| Where-Object { $_ } | ForEach-Object { $host.ui.WriteVerboseLine($_)} }
                    "Debug"       { $IndividualJob | Select-Object -ExpandProperty Debug| Where-Object { $_ } | ForEach-Object { $host.ui.WriteDebugLine($_)} }
#                    "Information" { $IndividualJob | Select-Object -ExpandProperty Information| Where-Object { $_ } | ForEach-Object { $host.ui.WriteInformation($_)} }
                    "Warning"     { $IndividualJob | Select-Object -ExpandProperty Warning| Where-Object { $_ } | ForEach-Object { $host.ui.WriteWarningLine($_) } }
                    "Error"       { $IndividualJob | Select-Object -ExpandProperty Error | ForEach-Object {$host.ui.WriteErrorLine($_)} }
                    "Output"      { $IndividualJob | Where-Object { $_ } | Select-Object -ExpandProperty Output }
                }
            }

        }
    }
}

@MVKozlov
Copy link
Contributor

MVKozlov commented May 5, 2017

I think will be better to ask @proxb why $host.Ui.Write functions used instead of Write-cmdlets

@AWahlqvist
Copy link

This also makes it very hard to use this module in for example Azure Automation, the error output is simply "lost" when the $host.Ui.Write functions are used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants