Yeah - I think -e should still exit with an error code. On Mon, Apr 18, 2016 at 1:33 AM, Daniel Kuppitz <m...@gremlin.guru> wrote:
> 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. > > >
