For Solr, I ended up having some slightly brittle logic to check if the argument is “zk” and then remove that one argument from the list of args, and then pass it on to the sub command (which didn’t expect a leading “zk” in it’s args). It works, but one wrinkle is that you would expect “bin/solr zk -h” to provide help on all the sub commands. So I made a special “ZkHelpTool” that would run in that one instance, and it gathered up the help for each subcommand…. A bit awkward but did work…
Definitely hoping for a smoother approach! > On Aug 10, 2024, at 8:25 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > > As a comparison git supports sub commands (verbs) but only one at a time > AFAIC. I wonder if we could even parse in a deterministic manner more than > one verb and it's options... > > Gary > > On Mon, Jul 22, 2024, 6:54 AM Eric Pugh <ep...@opensourceconnections.com > <mailto:ep...@opensourceconnections.com>> > wrote: > >> Yes, I think you are getting to the what I am looking for. We are trying >> to move more logic from shell scripts to Java code. >> >> Right now the help command for ZK >> >> Bin/solr zk -h command is all done in shell scripts because we don’t have >> a single Java class that represents the “zk” command. >> >> Instead we have >> >> Bin/solr zk ls >> Bin/solr zk cp >> >> Etc, and each is backed by it’s own Java class with commons-cli: >> >> ZkLsTool >> ZkCpTool. >> >> Now, the other direction we could go is to have a single “ZkTool”, but >> then (I think) we would lose out on the nice set up of Options specific to >> each sub command… >> >> >> >>> On Jul 22, 2024, at 9:05 AM, Claude Warren <cla...@apache.org> wrote: >>> >>> As I understand the question: If I have a project that has input options >> of >>> "file" and "type" and output options with the same names I could >> currently >>> write the options as: --input-file, --input-type, --output-file, >>> --output-type (This is the current approach in the unreleased Rat 0.17). >>> However, it can simplify things if I can separate the command options >> into >>> "sub commands" so rather than using: >>> >>> progName --input-file inFile --input-type CSV --output-file outFile >>> --output-type XML argument1 argument2 >>> >>> I can write the command line using "input" and "output" as subcommands >> like >>> >>> progName input --file inFile --type CSV output --file outFile --type XML >>> argument1 argument2 >>> >>> I support this idea if we can reconcile it with the open issue around >>> multiple values for an option and how they are structured. >>> >>> It could be implemented by creating a "subCommand" that has a name >> ("input" >>> or "output" in the exampel above) and contains multiple non-exclusive >>> options (like an OptionGroup without the exclusion check (I think by >>> default there is one subcommand containing all the options if no >>> subcommands are specified). command line parsing then has to determine >> if >>> a token is a subcommand, and value on a multi-valued option, or an >> argument >>> to the program. >>> >>> Claude >>> >>> On Sun, Jul 21, 2024 at 1:19 PM Gary Gregory <garydgreg...@gmail.com> >> wrote: >>> >>>> Are you talking about configuring Commons CLI to run shell commands or >>>> lambdas (where you'd have those run shell commands)? >>>> >>>> Gary >>>> >>>> On Sun, Jul 21, 2024 at 5:12 AM Eric Pugh >>>> <ep...@opensourceconnections.com> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> In Solr-land, we have a set of commands that sub commands that each >> take >>>> various options: >>>>> >>>>> Bin/solr zk cp >>>>> Bin/solr zk ls >>>>> Bin/solr zk rm >>>>> >>>>> Right now we handle picking the right command via the shell (linux) and >>>> command (windows) scripts. Is there any interest or way in having >>>> commons-cli handle figuring out which sub command is being run and >> calling >>>> it? Or is that beyond the remit of what commons-cli does.. >>>>> >>>>> For reference, this is where we do our zk logic: >>>> https://github.com/apache/solr/blob/main/solr/bin/solr#L890 and >>>> eventually where we pick the command to run: >>>> https://github.com/apache/solr/blob/main/solr/bin/solr#L1015 >>>>> >>>>> >>>>> >>>>> Eric >>>>> _______________________ >>>>> Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | >>>> http://www.opensourceconnections.com < >>>> http://www.opensourceconnections.com/> | My Free/Busy < >>>> http://tinyurl.com/eric-cal> >>>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < >>>> >> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw >>>>> >>>>> This e-mail and all contents, including attachments, is considered to >> be >>>> Company Confidential unless explicitly stated otherwise, regardless of >>>> whether attachments are marked as such. >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >> >> _______________________ >> Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | >> http://www.opensourceconnections.com < >> http://www.opensourceconnections.com/> | My Free/Busy < >> http://tinyurl.com/eric-cal> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed < >> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> >> >> This e-mail and all contents, including attachments, is considered to be >> Company Confidential unless explicitly stated otherwise, regardless of >> whether attachments are marked as such. _______________________ Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
