In issue #32, it is reported that global options are not available at command level when placed before command name. I found this to be a defect in the identification of command names from arguments.
This method was not correctly accounting for global options with provided values. ie. in the example provided by @msabramo:
aptly-cli --server 10.3.0.46 repo_list
It would incorrectly determine the args_string to be "10.3.0.46 repo_list" thus expecting the command name to start with 10.3.0.46.
Proposed Fix
I propose the valid_command_names_from method be modified to remove all global options from the args. This way it correctly identify the command name(s).
This will result in the global_option_proc finding a non-nil active_command and thus provide it the global option.
Context
In issue #32, it is reported that global options are not available at command level when placed before command name. I found this to be a defect in the identification of command names from arguments.
https://github.com/commander-rb/commander/blob/0abbac486ea7d87f6f680aaf17d0e3cd136dbf73/lib/commander/runner.rb#L248-L251
This method was not correctly accounting for global options with provided values. ie. in the example provided by @msabramo:
It would incorrectly determine the
args_string
to be"10.3.0.46 repo_list"
thus expecting the command name to start with10.3.0.46
.Proposed Fix
I propose the
valid_command_names_from
method be modified to remove all global options from the args. This way it correctly identify the command name(s).This will result in the
global_option_proc
finding a non-nilactive_command
and thus provide it the global option.https://github.com/commander-rb/commander/blob/0abbac486ea7d87f6f680aaf17d0e3cd136dbf73/lib/commander/runner.rb#L395-L402
Fixes #32.