Re: [CLI] Handling sub commands?

2024-07-22 Thread Claude Warren
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
>
>


[CLI] [Discuss[ "Since" attribute

2024-07-22 Thread Claude Warren
Greetings,

We recently introduced the "deprecation" processing where in we track the
version when the option was deprecated in the DeprecationAttribute property
"since".

I think it makes sense to add a since property to the Option class as
well.  This would list the version at which the option became available.

By default it would not be displayed.  However options would be added to
the helpFormatter tool to display since as a column in the help page.

Is there any disagreement on this or other points at which the value should
be displayed?

-- 
LinkedIn: http://www.linkedin.com/in/claudewarren


Re: [CLI] Handling sub commands?

2024-07-22 Thread Eric Pugh
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  | 
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.



Re: [CLI] [Discuss[ "Since" attribute

2024-07-22 Thread Gary Gregory
That sounds reasonable. Are you planning to create PR?

Gary

On Mon, Jul 22, 2024 at 3:12 AM Claude Warren  wrote:
>
> Greetings,
>
> We recently introduced the "deprecation" processing where in we track the
> version when the option was deprecated in the DeprecationAttribute property
> "since".
>
> I think it makes sense to add a since property to the Option class as
> well.  This would list the version at which the option became available.
>
> By default it would not be displayed.  However options would be added to
> the helpFormatter tool to display since as a column in the help page.
>
> Is there any disagreement on this or other points at which the value should
> be displayed?
>
> --
> LinkedIn: http://www.linkedin.com/in/claudewarren

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org