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

Reply via email to