Hey!
When an error is triggered by RunE, usage is displayed. This is a bit odd at this point, the usage is likely to be correct. I am using RunE to be able to get the errors from Execute() to display a detailed report. I have to set SilenceUsage in each RunE command. Is that the expected workflow?
sadly this is expected because any change might break people. It probably about time someone with time called this v1 of cobra and we start cleaning up mess like this in a v2....
Yeah, SilenceUsage: true in the root command is likely always correct. You don't need to set it for every command, just the root one.
Thanks for the tips, both SilenceUsage: true and SilenceError: true on the root works OK for me. I still get usage with --help or when subcommand is missing. I print errors myself. Should I close the issue since there is no obvious next step?
@vincentbernat I am sorry that I am late to the conversation but I agree, I never liked that you had to put SilentUsage and SilenceErrors. I would think that --help should still work.
When a subcommand is missing and you have SilentUsage, that should be respected. @eparis what do you think?
I'd be fine with a change that made it respect SilenceError on a missing submodule...
Okay. I will work on a fix for that tonight. 馃憤
@vincentbernat I am unable to recreate the issue. When I use SilentErrors, it silences the out put of from the missing subcommand. Do you have any example code where this happens?
I was unclear. My initial report was about the fact that you have to use SilenceErrors/SilenceUsage to not display usage when there is an error in RunE. By using those, I have to handle error display myself too. However, usage and help are still working for me, either when asked explicitely or when a subcommand is missing.
So far, there is no bug for me anymore. I would prefer to not have to use SilenceErrors but I understand we cannot break other people setup.
Sorry to hijack, but I believe this is related (enough) :) -- As best I can tell, SilenceUsage silences the usage text even when the error is produced by the built-in argument and flag validation, before RunE is reached. I had incorrectly assumed usage would shown in that case, but not when a "generic application error" is returned.
Perhaps this could be controlled explicitly on a per-error basis by optionally wrapping errors in an error type that is checked alongside the SilenceUsage flag in Command.Execute(). I'm imagining something that looks like return cobra.SilenceUsage(err) from a RunE function.
Hi all,
Having faced the same issue I'd like to share that in the end I think the current behavior is fine.
The thing is that in Hyperledger Fabric as part of the command execution we perform additional checks on the command arguments and if those checks fail we do need the usage message to be displayed to the user. So, simply silencing usage before calling RunE wouldn't work for us, even if it were based on a different flag/setting.
Instead I have found that explicitly setting the SilenceUsage to true from within RunE (well, the associated function) when we are done with checking the arguments provides the level of control we need to dictate whether or not the usage message should be displayed on error.
So our RunE functions look something like this:
do some additional checks on args - in case of error return, usage gets displayed
set cmd.SilenceUsage to true to avoid displaying usage on other errors
proceed with function execution, in case of error return, no usage gets displayed
Hope this helps.
@lehors thanks, that was helpful. in my case I didn't need to do any extra checking on inputs so I was able to just use PersistentPreRunHook on the root command with cmd.SilenceUsage = true inside it.
This issue is being marked as stale due to a long period of inactivity
Most helpful comment
Hi all,
Having faced the same issue I'd like to share that in the end I think the current behavior is fine.
The thing is that in Hyperledger Fabric as part of the command execution we perform additional checks on the command arguments and if those checks fail we do need the usage message to be displayed to the user. So, simply silencing usage before calling RunE wouldn't work for us, even if it were based on a different flag/setting.
Instead I have found that explicitly setting the SilenceUsage to true from within RunE (well, the associated function) when we are done with checking the arguments provides the level of control we need to dictate whether or not the usage message should be displayed on error.
So our RunE functions look something like this:
do some additional checks on args - in case of error return, usage gets displayed
set cmd.SilenceUsage to true to avoid displaying usage on other errors
proceed with function execution, in case of error return, no usage gets displayed
Hope this helps.