I see. I didn't know that "start" is mandatory now. I am not sure if this case occurs, but we still have in bin/solr.cmd `IF "%SCRIPT_CMD%"=="" set SCRIPT_CMD=start` (see https://github.com/apache/solr/blob/7d6088381d918e4a94e8c3d2c20c1eb5be003186/solr/bin/solr.cmd#L393C1-L393C43), which is why I assumed it was optional.
And thanks for the PR Eric. :) On Sat, Sep 14, 2024 at 3:46 AM Eric Pugh <de...@yahoo.com.invalid> wrote: > Bin/solr start actually is mandatory now, I would have to look up when we > made that change. It feels like a while ago…. > > I will put up a pr and we can see how it feels. > > Sent from my iPhone > > > On Sep 13, 2024, at 5:05 PM, Houston Putman <hous...@apache.org> wrote: > > > > I thought we were eventually going to make `start` mandatory, thus no > > confusion when just providing bin/solr -v? > > > > Anyways, I'm not going to make a line in the sand. I just think '-v' > works > > better as "verbose", though I do understand others use it for "version". > > > > - Houston > > > >> On Sun, Sep 8, 2024 at 9:35 PM David Smiley <dsmi...@apache.org> wrote: > >> > >> Maybe both? Meaning, if "-v" is provided, start Solr in verbose mode > and > >> print the version number first. > >> > >> On Sun, Sep 8, 2024 at 2:34 PM Christos Malliaridis < > >> c.malliari...@gmail.com> > >> wrote: > >> > >>> Thanks Houston for your perspective and sorey for the late response. > >>> > >>> I have considered both outcomes and thought that going with the -v for > >>> version is more expected for new users. Usually CLI tools allow > something > >>> like "[command] -v" to get quick and easy the version of the CLI tool / > >>> command. In the case of "bin/solr -v", with -v for verbose, it would > >> start > >>> a Solr instance with the default values if I am not mistaken, which may > >> not > >>> be the expected output for new users that use -v to check if the tool > is > >>> successfully installed / accessible. > >>> > >>> With "version" as argument, like in "bin/solr version", the version > turns > >>> into a "tool" and it accepts inputs like flags. I would like to avoid > >> such > >>> tool to avoid further confussion and new ways of getting the same > >>> information in different ways, but we have cases where we might want to > >> get > >>> the version metadata of a solr instance, rather than the CLI tool > itself. > >>> For these cases, additional flsgs could influence the output. Whether > >> this > >>> causes more confussion or is to be expected may depend on how the > version > >>> information is printed / outputed now and in the future. > >>> > >>> It is also worth noting that our current logic parses the -v into the > >>> argument "version" and later executes the VersionTool. This behavior > >> could > >>> be replaced if we wouldn't have a VersionTool or if we follow your > >>> recommendation of using -v for verbose. > >>> > >>> So regardless of my proposal of using "-v" for version, your proposal > of > >>> using it for verbose is also reasonable. > >>> > >>> Therefore, I'd like to get more opinions / perspectives on that, so > that > >> we > >>> can decide for a the most suitable resolution and continue with the > >>> improvements. > >>> > >>> Best, > >>> Christos > >>> > >>> > >>>> On Fri, 6 Sep 2024, 22:15 Houston Putman, <hous...@apache.org> wrote: > >>> > >>>> Why keep "-v" and "-version" around? I'd much rather keep the very > >>>> widely-used "-v"="--verbose". > >>>> > >>>> Only supporting "bin/solr version" makes much more sense to me. And > I'm > >>> not > >>>> even particularly worried about back compat for this one. > >>>> > >>>> - Houston > >>>> > >>>> On Fri, Sep 6, 2024 at 1:10 PM Christos Malliaridis < > >>>> c.malliari...@gmail.com> > >>>> wrote: > >>>> > >>>>> Many thanks to Eric for handling all the conflicts so far and > >> creating > >>>> PRs > >>>>> in an instant. > >>>>> > >>>>> The next conflict we have in Solr is the -v flag. -v is used for > >>> version > >>>> in > >>>>> bin/solr.cmd (explicitly) and SolrCLI, for verbose (with the partly > >>>> removed > >>>>> uppercase variant -V for a special case) in multiple CLI classes, and > >>> for > >>>>> value in ClusterTool. Ticket SOLR-17442 > >>>>> <https://issues.apache.org/jira/browse/SOLR-17442> proposes to > >> replace > >>>> via > >>>>> deprecation "verbose" with "debug" (-d and --debug), keep -v for > >>> version > >>>>> and remove -v for "value". I hope this proposal is reasonable and > >> makes > >>>>> sense. Input, opinions and objections are of course welcomed as well. > >>>>> > >>>>> *P.S. I've read that arguments and flags should be distinguished, > >> even > >>>>> though I was using them interchangeably so far for the CLI. What we > >>> have > >>>>> been referring to so far were CLI flags, so I'll try to use the right > >>>>> naming from now on. A nice website with useful information that Eric > >>>> showed > >>>>> me is *https://clig.dev/. > >>>>> > >>>>> On Fri, Aug 30, 2024 at 7:51 PM Christos Malliaridis < > >>>>> c.malliari...@gmail.com> wrote: > >>>>> > >>>>>> Continuing with the next conflict, > >>>>>> > >>>>>> We use -p mainly for the port argument and it is currently used in > >>>>>> RunExampleTool and SolrExporter as such. -p is also used in > >>> ConfigTool > >>>>> for > >>>>>> --property, in PackageTool for --param, and in PostTool for > >> --params. > >>>>> This > >>>>>> is more of a "light" conflict, as it does not break any > >>> functionality, > >>>>> but > >>>>>> potentially causes confusion to new users. > >>>>>> > >>>>>> The port argument is one of the first arguments new users learn > >> when > >>>>>> starting Solr, and other tools use -p for port as well. Therefore, > >> I > >>>>>> propose to reserve -p for port, deprecate -p in ConfigTool, > >>> PackageTool > >>>>> and > >>>>>> PostTool in version 9.8 and remove it completely in 10.0. This > >> avoids > >>>>> false > >>>>>> expectations of providing a port number via -p for actions like > >> "solr > >>>>>> config" "solr package" or "solr post", which may lead to unwanted > >>>>> results. > >>>>>> The port argument may then be added like the solr url argument > >>>>> (--solr-url) > >>>>>> to all tools if necessary. > >>>>>> > >>>>>> If there are any objections, please let us know. I've created > >>>> SOLR-17431 > >>>>>> <https://issues.apache.org/jira/browse/SOLR-17431>, but it can > >> still > >>>> be > >>>>>> resolved and closed if we decide to take a different action. > >>>>>> > >>>>>> P.S. Since --param in PackageTool and --params in PostTool are used > >>> for > >>>>>> passing parameters, we can consider in another discussion to > >>> deprecate > >>>>> and > >>>>>> replace --param with --params. > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Tue, Aug 27, 2024 at 11:17 PM Christos Malliaridis < > >>>>>> c.malliari...@gmail.com> wrote: > >>>>>> > >>>>>>> Hello everyone, > >>>>>>> > >>>>>>> In order to start resolving the CLI argument conflicts from > >>>>>>> https://issues.apache.org/jira/browse/SOLR-17383, we started to > >>>>>>> deprecate (in 9.X) and remove or change (in 10.0/main) the > >>> overlapping > >>>>>>> arguments. I would like to use this thread for tracking each > >>> conflict > >>>>>>> resolution. > >>>>>>> > >>>>>>> A conflict may be a bug or limitation of the CLI, but also just a > >>>>>>> possible misinterpretation for new users. Therefore, we should > >>> decide > >>>>> for > >>>>>>> each conflict what action we should take for the upcoming versions > >>> of > >>>>> Solr. > >>>>>>> The current state can be tracked at > >>>>>>> > >>>>> > >>>> > >>> > >> > https://docs.google.com/spreadsheets/d/1ws44kN51WnGwQzOXc8KKRQ93TMgHSqIGb02MRWFel_U/edit?usp=sharing > >>>>>>> (work in progress). > >>>>>>> > >>>>>>> Starting with -h, it is currently used for printing the help > >>>> information > >>>>>>> (equivalent to --help) and for providing a hostname in > >>>>> RunExampleTool.java > >>>>>>> (equivalent to --host, in 9.X and main). > >>>>>>> I created https://issues.apache.org/jira/browse/SOLR-17423, which > >>>>>>> proposes the deprecation of -h for hostname in the context of > >>>>>>> RunExampleTool, and the removal of it in future major releases > >> (10.0 > >>>>>>> ongoing). > >>>>>>> > >>>>>>> If there are any objections, please let us know. > >>>>>>> > >>>>>>> Best, > >>>>>>> Christos > >>>>>>> > >>>>>>> On Fri, Jul 26, 2024 at 9:36 PM Christos Malliaridis < > >>>>>>> c.malliari...@gmail.com> wrote: > >>>>>>> > >>>>>>>> Hello devs, > >>>>>>>> > >>>>>>>> I would like to get some attention on overlapping arguments that > >> I > >>>> have > >>>>>>>> found and documented in SOLR-17383 > >>>>>>>> <https://issues.apache.org/jira/browse/SOLR-17383>. This was one > >>> of > >>>> my > >>>>>>>> "bad experiences" when I started working with Solr, so I think it > >>> may > >>>>> be > >>>>>>>> more important than I thought. > >>>>>>>> > >>>>>>>> With the great work and progress of Eric Pugh moving parts of the > >>>>>>>> scripts to Java and my contribution in finding usages of > >> deprecated > >>>>>>>> arguments, I got even more curious to identify and document the > >>>>> overlapping > >>>>>>>> arguments in both short and long terms. > >>>>>>>> > >>>>>>>> I am not sure what would be the best way to address this, but I > >>> think > >>>>> we > >>>>>>>> can improve some arguments in various ways, now that we have > >>> already > >>>>>>>> started deprecating the usage of specific arguments and argument > >>>>> formats. > >>>>>>>> > >>>>>>>> Now that we have moved the argument parsing to Java, we could > >>>>> eventually > >>>>>>>> make use of Java's inheritance and leverage some arguments like > >> the > >>>>> Solr > >>>>>>>> URL, --help or --verbose to make them available in all cases if > >>>>> applicable. > >>>>>>>> > >>>>>>>> Best, > >>>>>>>> - Christos > >>>>>>>> > >>>>>>> > >>>>> > >>>> > >>> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
