Re: [CLI] Handling sub commands?

[Gary Gregory]

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 
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  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 
> 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
> >>  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.
>
>

Re: Modeling a "ls" or "cp" type command?

[Gary Gregory]

Darn, did you ever get any feedback on this?

Gary

On Wed, Jul 24, 2024 at 3:51 PM Eric Pugh
 wrote:
>
> In poking around, I’m seeing that it’s not obvious how to model a command 
> like the classic “ls” or “cp” commands with the usage.
>
> If I do “man cp” the output looks like:
>
> NAME
>  cp – copy files
>
> SYNOPSIS
>  cp [-R [-H | -L | -P]] [-fi | -n] [-alpsvXx] source_file target_file
>
> It shows the command, the various options, and then the args that it takes, 
> in this case source_file and target_file.
>
> In my Solr command line tools, I have not yet figured out how to model this.  
>  For example, the “ZkLsTool”, which is basically like the classic “ls” tool, 
> when I ask it for usage I get:
>
> usage: bin/solr ls --path  [-r ] [-u ] [-url 
> ] [-v] [-z ]
>
> List of options:
> --path  Path to list.
>  -r,--recurseRecurse (true|false), default is false.
>  -u,--credentialsCredentials in the format 
> username:password. Example: --credentials solr:SolrRocks
>
>
> However, I don’t want the path to be the option —path.   In Solr today, we do 
> some swapping around in the bin/solr command to convert a “bin/solr zk ls 
> /mypath” into a call that is to SolrCLI ls —path /mypath to fit how commons 
> works.
>
> We are however trying to remove the argument parsing in the shell command and 
> learn more on commons-cli.
>
> Thoughts on this?   Do we need to have an Argument class to go along with the 
> Option class?
>
> Eric
>
>
> I___
> Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 | 
> http://www.opensourceconnections.com  
> | My Free/Busy 
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 
> 
> 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

[VOTE] Release Apache Commons CLI 1.9.0 based on RC1

[Gary Gregory]

We have fixed a few bugs and added enhancements since Apache Commons
CLI 1.8.0 was released, so I would like to release Apache Commons CLI
1.9.0.

Apache Commons CLI 1.9.0 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/cli/1.9.0-RC1 (svn
revision 70780)

The Git tag commons-cli-1.9.0-RC1 commit for this RC is
698b238276c0e22e97e4aec703a0b00201d29666 which you can browse here:

https://gitbox.apache.org/repos/asf?p=commons-cli.git;a=commit;h=698b238276c0e22e97e4aec703a0b00201d29666
You may checkout this tag using:
git clone https://gitbox.apache.org/repos/asf/commons-cli.git
--branch commons-cli-1.9.0-RC1 commons-cli-1.9.0-RC1

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1768/commons-cli/commons-cli/1.9.0/

These are the artifacts and their hashes:

#Release SHA-512s
#Sat Aug 10 13:08:27 UTC 2024
commons-cli-1.9.0-bin.tar.gz=f3ed06d0269c38eaf0505751468e137807003741772bfc3b88aa6547f974f43bf6daa2c649d745a3eedae5e01ede1c730df0a63ee5ce7abc504ed5858d9ba7df
commons-cli-1.9.0-bin.zip=6df718dae338caeb8905db0bcd9e1c147c60796a11c30a3c9eaaff5035492e2db21cdb496a4e47769339c1da7930ad8742d4976b9688d37f30ab2e40caf7dcec
commons-cli-1.9.0-bom.json=0bdb44676d6bd310b614ade5c5728f79ecf7dbb3c5982ae9758a38361dc56838258a24f19b2d9560ebe0741df476c3a58c6226f60be2d2182577c2d003625441
commons-cli-1.9.0-bom.xml=c0aae3650e695986369e37a8690031d14d3db28b511840ff872b6eeb4ba4ff792add198fa22d1e09581904542012fd539c2df632599b09edae3c0ea4f5edc94a
commons-cli-1.9.0-javadoc.jar=b581820ab885fc1c7326537d5135cce4c25e40b16234441015b77edb4e2dbe70e0bcda198783761ccf56983161b84d95a835a1dfe4316afb70240b4947522ef7
commons-cli-1.9.0-sources.jar=ff4268d93d10cb9a5373c4a2c9a71bf2b9ce9abfc2cdc9d7c2f2fcfe10462929b10025e7e68cc118bf825b26c3bfc5bf7fa83ef20542e8f15a9036386d9597d5
commons-cli-1.9.0-src.tar.gz=d20df809e8e0ebed79c57af9c9b447b0068347ba0edfcdec3652cb00bd9575b24fc77093d735e827d9d02a6fe2681bf239fd01df5f7c682ae34ade0781c53e35
commons-cli-1.9.0-src.zip=604b0329afd92b13a662549b02f68d11a71828a8745a74e2b08f912ae2d35814bd4f6278f3f74c9a24b55e6854a1af420848ed1f6182a29f6d30bb3568ad6e55
commons-cli-1.9.0-test-sources.jar=ef6d16ecb4cf01e3901df9451afb35bf2a122e6ff4af4d4b99560f9cb48933620a8f33cc810f4bcc5f9bff7ee6189e22b9300bd4619240d1b7aea55bd30aed31
commons-cli-1.9.0-tests.jar=ae995be6121589a321df596825d17d9379df88c9d6a23ada05879ef3a7a9c77865857b4b84c981c4b79a6da710a1d4837c2830cdc312690568ab83882225f94b
commons-cli_commons-cli-1.9.0.spdx.json=444a59cece554fd97441de8cc411575ea715348cf5803e07ca1c28351cfba78c9849ea40ea4d11b0e73d5c72755d7041f8373596382a4b77062d2cb1a6335824



I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy
-P jacoco -P japicmp clean package site deploy ' using:

openjdk version "17.0.12" 2024-07-16
OpenJDK Runtime Environment Homebrew (build 17.0.12+0)
OpenJDK 64-Bit Server VM Homebrew (build 17.0.12+0, mixed mode, sharing)

Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256)
Maven home: /usr/local/Cellar/maven/3.9.8/libexec
Java version: 17.0.12, vendor: Homebrew, runtime:
/usr/local/Cellar/openjdk@17/17.0.12/libexec/openjdk.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "14.6.1", arch: "x86_64", family: "mac"

Darwin gdg-mac-mini.local 23.6.0 Darwin Kernel Version 23.6.0: Mon Jul
29 21:13:00 PDT 2024; root:xnu-10063.141.2~1/RELEASE_X86_64 x86_64

Details of changes since 1.8.0 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/cli/1.9.0-RC1/RELEASE-NOTES.txt

https://dist.apache.org/repos/dist/dev/commons/cli/1.9.0-RC1/site/changes-report.html

Site:
https://dist.apache.org/repos/dist/dev/commons/cli/1.9.0-RC1/site/index.html
(note some *relative* links are broken and the 1.9.0 directories
are not yet created - these will be OK once the site is deployed.)

JApiCmp Report (compared to 1.8.0):

https://dist.apache.org/repos/dist/dev/commons/cli/1.9.0-RC1/site/japicmp.html

RAT Report:

https://dist.apache.org/repos/dist/dev/commons/cli/1.9.0-RC1/site/rat-report.html

KEYS:
  https://downloads.apache.org/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now.

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thank you,

Gary Gregory,
Release Manager (using key 86fdc7e2a11262cb)

The following is intended as a helper and refresher for reviewers.

Validating a release candidate
==

These guidelines are NOT complete.

Requirements: Git, Java, Maven.

You can validate a release from a release candidate (RC) tag as follows.

1a) Clone and checkout the RC tag

git clone https://gitbox.apache.org/repos/asf/commons-cli.git --branch
commons-cli-1.9.0-RC1 commons-cli-1.9.0-RC1
cd commons-cli-1.9.0-RC1

1b) Download and unpack the source archive from:

https://dist.apache.org