-
Notifications
You must be signed in to change notification settings - Fork 903
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
The operation completed successfully on stderr #249
Comments
Running this by hand, what is the exit code?
Keep in mind that |
Out of curiousity, did it work in 0.9.8.33? That one was a bit better at detecting errors than its predecessors. |
Running from a command shell
Running from a powershell:
Yes, it does work without issue on my systems that are still running 0.9.8.33... |
Any chance I can get the package in question (or one that has the same issues) for local testing? |
Yes, you can download it from https://www.myget.org/F/dcjulian29-chocolatey/api/v2/package/mysettings-ntfs/2014.5.17 |
This is a tough one. Adding |
Okay, so reg.exe import C:\ProgramData\chocolatey\lib\mysettings-ntfs\tools\registry.reg /reg:64 Exits with this status:
And an exit code of 0. Why that is getting fed to the error stream in what remains to be seen. |
At this reference note this: If InStr(1,oExec.StdErr.ReadAll,"operation completed successfully",vbTextCompare) Then
' Yes the success text IS sent out via StdErr and NOT StdOut
WScript.Echo "Registry updated sucessfully"
oFSO.DeleteFile sTempFile
Else
WScript.Echo "regWriteBinary: Registry import of " & sTempFile & " failed: " & oExec.StdErr.ReadAll
End If
|
This actually looks like an issue with reg.exe and not with new/old Chocolatey. Or rather the POSH version of choco was maybe forgiving on this. I did flip over to 0.9.8.33 and it has no issues installing and it appears to return the message back as what looks like no error at all. I'm not quite sure what the correct path forward is. |
I believe the whole reason I switched to using the reg.exe tool was because sometimes PowerShell gets confused on the "bitness" of the registry if the PowerShell host is running the 32-bit shell on a 64-bit operating system when using the the PowerShell Registry Provider to change the registry... I think I can work around this by calling out to the underlying .Net API to deal with the registry after determining if the system is 64-bit... $key = [Microsoft.Win32.RegistryKey]::OpenBaseKey([Microsoft.Win32.RegistryHive]::LocalMachine, [Microsoft.Win32.RegistryView]::Registry64)
$subKey = $key.OpenSubKey("SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management", $true)
$subKey.SetValue("DisablePagingExecutive", 1) I believe the path forward is to not fault Choco for "doing the right thing" and to possibly submit a bug against the underlying tool being called from the script... Based on your research and discoveries, it doesn't appear to be a bug in chocolatey. |
Unfortunately this is not just local to reg.exe. Perhaps the right thing to do is workaround it. :/ |
It seems that many applications out there can return this error and still exit with a zero exit code, when this is logged within the PowerShell service runner, it should redirect that back to the info stream and not count it as a fail point. If PowerShell does exit with a non-zero status, then we should count the whole install as a failure no matter what messages were logged. In this way the exit code 0 and the message "The operation completed successfully" are not considered a failure. References: https://rcmtech.wordpress.com/2012/03/06/vbscript-and-reg_binary-registry-values/ http://en.community.dell.com/techcenter/powergui/f/4833/t/19570669 >I've found the problem. The main problem is in reg.exe utility. >Depending on the version reg.exe utility works differently. v5.1.x.x (that I have on my XPSP3) works correctly, but v5.2.x.x does not work as it is expected to work. >"reg import" command: >- when v5.1: returns "Operation completed successfully" to standard OUTPUT stream >- when v5.2: returns "Operation completed successfully" to standard ERROR stream >Moreover, it is probably a problem with PowerShell also :( >PowerShell treats these streams differently and process ERROR stream messages as errors. Which is correct imho.
* stable: (GH-249) Fix "operation completed successfully" on stderr (maint) ApplicationParameters are readonly (maint) remove spec logging
Fixed in 9936876 and will be released with 0.9.9.7. |
When running PowerShell operations, use a built-in PowerShell host by default, allowing fallback to the older method of running Posh by calling an external process. By building against the oldest version of System.Management.Automation that aligns with the oldest Windows Operating Systems supported, we can guarantee this will work on every version of Windows where Chocolatey is supported. In case we do run into issues, attempt to resolve the PowerShell assemblies starting from the newest version and falling down to the older versions until one is resolved or no version is resolved. There is a known assembly that will go through this process every time - System.Management.Automation.resources, en-US. To see those assemblies go through, one must ask for both debug and verbose output. This reverts the changes for chocolateyGH-249 in 9936876 and the changes from chocolateyGH-349 in 344268b so that both paths (system powershell and choco's built-in PowerShell) run with similar output and because by default in d523e7b (chocolateyGH-445) choco no longer fails on the presence of stderr output.
I have no idea what Choco is -- and I apologize for derailing -- but this bug report is the top google search result for
And usage is pretty simple:
Hope that's helpful for someone, somewhere. :) |
Thank you @BrainSlugs83 that has come in helpful! |
I have a package that "works" in 0.9.8 and has started to be "unsuccessful" when installed on computers running the new choco 0.9.9. I've run the package on both Windows 8.1 and 10 and get the same:
and the package fails to install. This specific package changes some registry settings and I've verified that they are indeed changed. I've also updated the install script to output the $LastExitCode after each line in the script and don't see any non-zero exit codes...
Console Output: https://gist.github.com/dcjulian29/e38de448ce54af997137
Chocolatey Log: https://gist.github.com/dcjulian29/7b9deb1be194f4fe7ef6
The text was updated successfully, but these errors were encountered: