don't print help after successful command #33
Conversation
| handle_options | ||
| elsif have_command?(subcommand_name) | ||
| subcommand = instantiate_subcommand(subcommand_name) | ||
| exit_code = subcommand.run_with_default_options(subcommand_params) |
There was a problem hiding this comment.
I think other commands might be doing hacky stuff to remove the subcommand name from the argv array. This is much better, but we need to check each command to fix them for this change.
There was a problem hiding this comment.
Odd, I see now this is the same logic as before, but, for example, the verify command does this: https://github.com/opscode/chef-dk/blob/master/lib/chef-dk/command/verify.rb#L105 We should investigate that.
There was a problem hiding this comment.
Dan, it doesn't look like that unshift does anything (well, it prepends nothing to the array). The verify command doesn't get verify as a parameter, none of the subcommands get passed their name (https://github.com/opscode/chef-dk/blob/help-command/lib/chef-dk/cli.rb#L56).
There was a problem hiding this comment.
oh, derp. We should remove that, then. Good catch.
|
👍 |
don't print help after successful command
(chef-dk, stop being so helpful.)
sometimes help was printing after commands like
chef gem which chef\cc @opscode/client-eng