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

Error stream parsing #220

Closed
chris-rock opened this issue Sep 4, 2016 · 12 comments
Closed

Error stream parsing #220

chris-rock opened this issue Sep 4, 2016 · 12 comments

Comments

@chris-rock
Copy link
Contributor

Awesome project! We are using it heavily in InSpec and I would like to implement the following for Windows and InSpec:

# test stderr
describe powershell("Write-Error \"error\"") do
  its('stdout') { should eq '' }
  # this is an xml error for now, if the script is run via WinRM
  # @see https://github.com/WinRb/WinRM/issues/106
  # its('stderr') { should eq 'error' }
end

Since the error message is not parsed, I get the following error:

 Powershell stdout
     ✔  should eq ""
     ✖  should eq "error"\n
     expected: "error"
          got: "Write-Error \"error\" : error\n    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException\n    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException\n"

     (compared using ==)

     Diff:
     @@ -1,2 +1,4 @@
     -error
     +Write-Error "error" : error
     +    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
     +    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException

Do you have any good idea, how we can improve that?

@mwrock
Copy link
Member

mwrock commented Sep 4, 2016

There was alot of work in winrm v2 to make powershell stderr MUCH better. For example, on v2 the above stderr would now be:

irb(main):009:0> puts shell.run("write-error 'error'").stderr
write-error 'error' : error
    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException
=> nil
irb(main):010:0>

So no more crazy XML output.

@mwrock
Copy link
Member

mwrock commented Sep 4, 2016

We tried to make stderr the same as what you would see in straight up powershell. We may have missed some edge cases so please file issues if you see unexpected results.

Definitely try out inspec/train#122 against inspec and see if that produces the desired output for the above spec.

@chris-rock
Copy link
Contributor Author

I currently run the InSpec integration tests inspec/inspec#1018 with inspec/train#122

@mwrock
Copy link
Member

mwrock commented Sep 4, 2016

Oh I should have included this too:

irb(main):010:0> puts shell.run("write-error 'error'").stdout

=> nil

So stdout is now empty.

@chris-rock
Copy link
Contributor Author

@mwrock stdout is no issue. I was only discussing about stderr

@mwrock
Copy link
Member

mwrock commented Sep 4, 2016

oh ok. Are these specs in inpec? I can take a look.

@chris-rock
Copy link
Contributor Author

@mwrock
Copy link
Member

mwrock commented Sep 4, 2016

cool. will have a look now

@mwrock
Copy link
Member

mwrock commented Sep 4, 2016

I should have read the spec above more closely. So it sounds like what you are looking for is to have stderr equal the message spit out from write-error. Currently, the WinRM::Output returned from run will return stderr matching what powershell would return. To get just error, you'd really need to do something like:

write-error 'error'
$err = $Error[0]
write-output $err.Exception.message

Then you'd see err from stdout

@chris-rock
Copy link
Contributor Author

@mwrock Alright. Got you. I'll update the integration tests to expect the full error string.

@mwrock
Copy link
Member

mwrock commented Sep 4, 2016

The :powershell shell does expose a send_pipeline_command which is so far undocumented. It returns an array of low level PSRP response messages that could be parsed for the specific error message.

@mwrock
Copy link
Member

mwrock commented Sep 4, 2016

I think you could find the message that hase a type of WinRM::PSRP::Message::MESSAGE_TYPES[:error_record] and then look at message.parsed_data.exception[:message]

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

No branches or pull requests

2 participants