I've seen a few projects where it was preferred that the console exits after processing the script (script were triggered via nightly cron jobs). So just for clarification - is that what -e will (continue to) do in the future (also in case of errors in the script) or do we have to add an explicit System.exit() (but then what about errors in the script)?
Cheers, Daniel On Sun, Apr 17, 2016 at 3:35 PM, 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. >
