> gremlin-server.sh uses -i to install plugins, so I'd pick a different flag here.
dah...that stinks. groovy uses -e and python is -i. since we'd already used -e i figured that -i would at least match python. hard to do better than -i for gremlin.sh as it's quite memorable for being "interactive mode". it's so good, i'd almost ignore the fact that gremlin-server.sh provides different meaning to it. anyone have other ideas for what it could be? jason do you feel really strongly about using something different? > 3.1.3? This isn't considered a breaking change? no - i think it can be done to be backward compatible. if i find it can't i'll make sure it happens in 3.2.1. On Mon, Apr 18, 2016 at 10:53 AM, Jason Plurad <plur...@gmail.com> wrote: > > 3. Add support for bin/gremlin.sh -i init.groovy > > gremlin-server.sh uses -i to install plugins, so I'd pick a different flag > here. > > > I plan to experiment on these changes in the coming days for 3.1.3 > > 3.1.3? This isn't considered a breaking change? > > -- Jason > > > On Sun, Apr 17, 2016 at 9:35 AM, Stephen Mallette <spmalle...@gmail.com> > wrote: > > > We currently have a couple ways to pass files to Gremlin Console for > > execution. We have: > > > > bin/gremlin.sh init.groovy > > > > and > > > > bin/gremlin.sh -e exec.groovy > > > > where the first one executes an initialization script for the console and > > then leaves the console open (unless there is a failure in executing the > > script) and the the second executes a script through the ScriptExecutor > and > > takes arguments that configure the script. > > > > Both have their uses, but ScriptExecutor and -e are a hold-over from > > TinkerPop 2.x and they introduce a bit of an incongruity where a script > > that will run for the first command may not work when used with -e. > > ScriptExecutor is a wrapper for a standalone GremlinGroovyScriptEngine > and > > therefore does not allow console commands to be executed. So if your > > exec.groovy contained: > > > > :remote connect tinkerpop.server conf/remote.yaml > > :> 1 + 1 > > > > because you were doing some automation with Gremlin and wanted to > execute a > > remote script, you will get a failure. I think we have a fair bit of > room > > for improvement here and as of Groovy 2.4.x there are some changes in > > groovysh that will allow us to drop some of our own internal code for > doing > > these kinds of things. > > > > I'd basically propose that we: > > > > 1. Deprecate support for ScriptExecutor - it's too confusing to have > these > > scripts execute in different ways through gremlin.sh. > > 2. Deprecate support of bin/gremlin.sh init.groovy (stop encouraging this > > usage pattern) > > 3. Add support for bin/gremlin.sh -i init.groovy which does the same > thing > > as (2) and does not exit the console on failure. That would allow a user > to > > work with their console session up to the point of failure. > > 4. Improve support for bin/gremlin.sh -e exec.groovy to no longer use > > ScriptExecutor and execute scripts directly in the console for automation > > purposes. > > 5. Add some other options to control output to the console so that you > > could do bin/gremlin.sh -q -e exec.groovy which would execute in a quiet > > mode with no output, for example. > > 6. Groovy's shell lets you do groovysh script1.groovy script2.groovy, > > script3.groovy..... We could do something like that too if we wanted, but > > we currently allow for something Groovy's shell does not: script > arguments. > > I suppose we could do the multi-file thing and have some syntax for > passing > > command line arguments. maybe like: bin/gremlin.sh -e script1.groovy > > [argument1 argument2] script2.groovy [arg1] - I don't think we could do > > this without a breaking change though, so perhaps we worry about this for > > 3.3.x whenever we get around to working on that. > > > > I plan to experiment on these changes in the coming days for 3.1.3. > Please > > let me know if there are other thoughts on this matter. > > >
