Darn, did you ever get any feedback on this? Gary
On Wed, Jul 24, 2024 at 3:51 PM Eric Pugh <ep...@opensourceconnections.com> 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 <PATH> [-r <recurse>] [-u <credentials>] [-url > <HOST>] [-v] [-z <HOST>] > > List of options: > --path <PATH> Path to list. > -r,--recurse <recurse> Recurse (true|false), default is false. > -u,--credentials <credentials> Credentials 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 <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