powershell_script returns 0 for scripts with syntax errors

[awithersdd]

I submitted this PR: #2244 but it only adds a test showing the problem.

The following:

powershell_script "fail" do
  code <<-EOS
    if (Test-Path .) echo foo
  EOS
end

Will indicate that "fail" ran successfully. It did not, powershell reported a parse error. Basically if you make a syntax error in your powershell script the only evidence of failure will be that whatever it was supposed to do will not be done.

I understand there are two needs here, one is to have the actual value of the error code but I'd put syntax error reporting above error code matching (-Command vs -File). The only solutions I had for this are terrible.

[sersut]

/cc: @adamedx

[carpnick]

Fixed this by calling out to Powershell 2 times per script call in a private gem. Not the best implementation but works.

          def syntax_check 
            local_script_contents=("function testme(){ \n #{@originalScript.to_s} \n} \n")

            result = run_command(shell,flags,filename,file_extension, local_script_contents, @options, false)
            if(result.stderr.length >= 1 || result.exitstatus !=0)
              raise RuntimeError,"Did not syntactically pass the powershell check.  \n Standard out: #{result.stdout} \n Standard Error:#{result.stderr}"
            end
          end

[adamedx]

That's not unreasonable @carpnick -- we could probably just include the block twice in the script in the provider to see if that triggers errors for non-wellformed methods.
In general, the problem is with the trap statement generated by the provider -- if we don't exit in the handler, everything is fine.
I do have another working solution that is a little simpler -- it relies on using a global to detect that the trap handler was triggered (not great), and double-checking with the return result of the script block (not terrible) which must be $null in that case.
I'll send a pr with the example if I can get it to pass specs.
cc @jdmundrawala , @btm.

[ksubrama]

The fix has been merged in #3080