Thanks for the background guys. To echo/further what Ishan and Erick said above, my own ignorance of Windows scripting is what initially brought this to mind. I've had a handful of JIRA's grind to a halt because of this recently.
I've created SOLR-11206 (https://issues.apache.org/jira/browse/SOLR-11206) for this. I've tried to sum up the discussion here in that JIRA description; please add any corrections if I've misinterpreted anything. I hope to do more digging on this in the next day or so. On Mon, Aug 7, 2017 at 11:52 AM, Erick Erickson <[email protected]> wrote: > Ditto the pain of working both with the *nix script and the Windows > scripts. I don't have ready access to Windows machines either so have > to rely on the kindness of people who do when I need to modify the > scripts. I think it was one of those things that started out with a > simple script and each addition was easier to add to the scripts than > move everything to Java. Until it became a monster. > > One point of clarification: I _think_ Anshum meant moving the command > parsing and all that rot out of the scripts, not the ability to invoke > the commands themselves. > > So if you have the time/energy to take it on, please do create a JIRA... > > Best, > Erick > > On Mon, Aug 7, 2017 at 8:40 AM, Ishan Chattopadhyaya > <[email protected]> wrote: >> There's https://issues.apache.org/jira/browse/SOLR-7871 which has some >> relevant discussion in these painpoints. >> Frankly, working with solr.cmd has been one of the toughest things I've had >> to deal with in last few months (thanks to my inability to work with Windows >> script). >> >> On Mon, Aug 7, 2017 at 10:19 AM, Anshum Gupta <[email protected]> >> wrote: >>> >>> Hi Jason, >>> >>> The history behind the scripts is that they were simpler, and were done to >>> make things easier for end users. Not sure if you have worked with the >>> 'bootstrap' part of the command that predated these scripts, but the >>> intention was to move away from those. >>> >>> There was an intention to move the code that can be moved to Java, and do >>> the heavy lifting there, considering that would also mean reduplication of >>> code between the *nix, and the windows scripts but due to lack of bandwidth, >>> that was never done. >>> >>> It'd be great to get a patch on the same and have this move out of the bin >>> scripts altogether. Feel free to create a JIRA and start working on it. >>> >>> In case someone else more to add, please do. >>> >>> Anshum >>> >>> On Sun, Aug 6, 2017 at 7:43 PM Jason Gerlowski <[email protected]> >>> wrote: >>>> >>>> I noticed recently that arg validation/parsing/help-text for the >>>> "create", "delete", "auth", "zk", etc. commands makes up a huge chunk >>>> of the (bin/solr) scripts. (Some 600 lines by a quick count!) >>>> >>>> This is a shame, since that logic is duplicated across two >>>> platform-specific scripts. >>>> >>>> I'm not familiar with the history of these scripts; is there a reason >>>> this logic lives here? I know that some args must be examined before >>>> we enter Java-land ("--verbose", JVM args, come to mind). But is >>>> there a reason the other arguments are parsed/examined there as well? >>>> >>>> If there's not, moving that logic to Java would gain us a few things: >>>> >>>> - removes duplication >>>> - makes test-writing for this logic possible >>>> - Java-logic is more accessible/readable to some than bash/Windows-shell. >>>> >>>> Is there anything I'm missing about this logic living in the bin >>>> scripts? I'm happy to create a JIRA and do the leg-work for the >>>> change if this is something we're interested in. Just wanted to ask >>>> around before starting, due to my lack of background. >>>> >>>> Thanks for clarification, if anyone has any to offer. >>>> >>>> Best, >>>> >>>> Jason >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
