Exec mode...

[sean-]

One of the things that keeps coming up is the use of gomplate as a pre-processor followed by the execution of a binary. It would be nice if it were possible to do something like:

gomplate ${GOMPLATE_FLAGS} --exec="consul -config-dir /usr/local/etc/consul.d/"

# or a more preferred option:

gomplate ${GOMPLATE_FLAGS} -- consul -config-dir /usr/local/etc/consul.d/

so that gomplate can literally be used as a preprocessor without resorting to a shell script to stitch these two commands together.

#featurerequest

[hairyhenderson]

🤔

I've thought about gomplate spawning processes in the past, and I'm definitely not a fan of having a template control this (huge potential for abuse if templates are ever user-provided).

Having a process spawned after template execution, based on commandline args, on the other hand, isn't as dangerous IMO. But it's still a little beyond what gomplate is really designed for...

This can also always be done with a shell - something like:

$ sh -c "gomplate ${GOMPLATE_FLAGS} && consul -config-dir /usr/loca/etc/consul.d/"

Is there any compelling reason you don't want to do that?

[sean-]

sh(1) is POSIX-specific. If gomplate(1) exec'ed a sub-command and was explicitly one-shot, then it becomes reasonable to chain commands together and expect signal handling will work as expected, which is convenient for things like nomad or other cluster schedulers. Nested shell escaping is something to be avoided, too, which is why I like the second option more than the first (i.e. everything after -- is passed along as args to Exec()). As for precedent, env(1) comes to mind, same with consul-template.

In particular, I want to update a consul key and have nomad relaunch the job and use gomplate to render out the value before starting the child process.

?

[hairyhenderson]

Thanks @sean-, you've convinced me 😉

[osterman]

Just for some other examples.... use-cases, we're chaining other commands like this aws-vault exec profile -- chamber exec kops -- helmfile sync. Would be helpful to use gomplate as a preprocessor for this workflow the way @sean- proposes.

e..g

gomplate --in helmfile.yaml --out helmfile.yaml exec -- \
    aws-vault exec profile -- \
    chamber exec kops -- helmfile sync

[hairyhenderson]

@sean- can you have a look at #307 and let me know what you think of usage?

[sean-]

I think that is basically spot on with the original suggestion. I'm still noodling on the exec subcommand mentioned in #307 . I think -- is safe because gomplate doesn't have another mode of operation right now and it's not like tar(1), for instance, where you'd want to stop arg processing and allow arbitrary arguments to be passed to tar. In this case, you want to stop arg parsing at -- and unconditionally pass the result to exec(2).
Regardless of where you land on that, +1.