> 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. >
