The interactions between shells (such as bash, in my case) and the G’MIC command processor are hard to predict, given that the two interpreters share many “special characters.” See Post 128 in Tutorial Fragments concerning how best to present G’MIC code examples. The gist of that discussion is (1) for uncomplicated settings, use the G’MIC run command, and for more complex settings (2) write a small custom command.
Both approaches attempt to shield G’MIC pipelines from the shell interpreter, which processes what people write following a prompt first, and which may alter the composition of what people write before G’MIC has a chance to process it. So:
$ gmic run '<G'MIC pipeline>'
That is, pass the pipeline as a quoted argument to the run command, which creates a custom command on-the-fly and runs it, shielding the pipeline from prior command shell filtering. This creates a more controlled environment, rather like the “non-interactive” setting.
The more sophisticated approach is to write a custom command directly:
foo:
<G'MIC pipeline>
and put that in foo.gmic or some such, then:
$ gmic -m foo.gmic foo
The latter approach is more involved, but far more flexible.
The next tutorial release, somewhere in September, will be discussing this problem (and solutions) as shell/G’MIC conflicts create no end of confusion for both beginners and people who have been scripting G’MIC for awhile.