I have strange problems calling lots of filters from the CLI on Windows, using 2.9.2 and 2.9.3 with the latest updates downloaded. Here is an example for fx_asciiart:
./gmic -input sample.png -fx_asciiart -display
[gmic]-0./ Start G’MIC interpreter.
[gmic]-0./ Input file ‘sample.png’ at position 0 (1 image 750x500x1x3).
[gmic]-1./ *** Error *** Command ‘fx_asciiart’: Undefined argument ‘$7’, in expression ‘$7’ (for 12 arguments specified).
Does anyone have an idea what I could be doing wrong here? I tried giving the full parameter string with default values (-fx_asciiart 5," .oO0",16,15,16,2,0,0.2,0,0,"",“gmic_asciiart.txt”), same results, so I suspect the problem elsewhere, either in my configuration or in the way I am calling the interpreter. Increasing the verbosity level did also not help. As I said, similar things happen with other filters as well.
I’ve just checked that it works for the plug-in.
Now, from the command line, I get something similar as you:
$ gmic sp lena fx_asciiart 5," .oO0",16,15,16,2,0,0.2,0,0,"/home/dtschump/Desktop","gmic_asciiart.txt"
[gmic]-0./ Start G'MIC interpreter.
[gmic]-1./ Input sample image 'lena' (1 image 512x512x1x3).
[gmic]-1./ *** Error *** Command 'fx_asciiart': Undefined argument '$7', in expression '$7' (for 12 arguments specified).
..
But there is an explanation for this : in bash, when you specify an argument argv[] with spaces enclosed in double quotes (as it’s the case here with the " .oO0" part), then gmic takes the whole argument (here, 5," .oO0",16,15,16,2,0,0.2,0,0,"/home/dtschump/Desktop","gmic_asciiart.txt") as double-quoted.
The reason for doing that is gmic must be able to read filenames with spaces in it, e.g. with $ gmic "filename with spaces.png", without trying to split it in multiple items.
Now, the solution to make fx_ascii_art work from the command-line, is to escape the double-quotes:
$ gmic sp lena fx_asciiart 5,\" .oO0\",16,15,16,2,0,0.2,0,0,"/home/dtschump/Desktop","gmic_asciiart.txt"
but only for the argument that contains a space.
And of course, this is a bash-related issue, the initial string works just fine if you copy/paste it in a .gmic command file.
Maybe that’s related to your issue ?
Under my MaxOS Terminal this
gmic osteo fx_asciiart 5,\\ .oO0,16,15,16,2,0,0.2,0,0,"",“gmic_asciiart.txt”
works quite well!
Ah, it makes sense now! I tested with escaping the quotes, but did this for all arguments, not only for the ones containing spaces. using your line, it works now, sorry for the confusion and good to remember that.
Mixing G’MIC syntax and bash-syntax actually always requires a bit of attention 
Yeah, especially for people like me who usually work with command files or directly in the C/C++ API. I actually just had to check why a command failed in my plugin, so I tried it out on the command line. But I’ll learn
gmic-py could help prevent you from escaping things a bit… as it runs outside of bash, and Python does not have magic symbols inside strings.
ok… but it is not ready on Windows at all for now… just windows subsystem linux and the display shall not work…
For all these issues I actually created the G’MIC bridge years ago, which is now called libcgmicstatic and is included with each G’MIC release. It is basically the G’MIC CLI interface, but callable as a C function. This has the advantage that it can be compiled using MinGW, and results in a totally self-contained library without any external dependencies (not even on G’MIC/CImg). Since this is also a pure ANSI-C library, it can be linked and used in other compilers like Visual Studio without problems. So adapting G’MIC/bridging it to other languages that support C-bindings is very easy.
Thanks for reminding!
I am reading the libcgmic code again…
I had tried to start from it in November 2019, thinking that I could use the Python ctypes module to load shared libraries symbols from Python’s symbol reader API… but gave up in order to have much more control.
Actually what I expose in gmic-py in order to make a .dll / .so is pure C, because only C Python API symbols are exposed. Then inside I wrap C++ a bit similarly to you, except that image names are tied into the Gmic Image type but a separate plain python list os strings. Also, on gmic-py, interleaving is not written inside the Gmic Image type and is not stored anywhere, so people have to display or output images themselves to understand if their de/interleaving is in a broken state. Maybe I have made a mistake of not building libcgmic, but for now it seems that the problem on Windows is not about building libgmic and including it statically, but about my Python C abstraction and especially the proper build system setup (Python extensions get built through setup.py which semi-autodetects per-OS compiling settings).
I remember that the blender-custom-nodes project used the libcgmic… so I am sure that many projects have been benefitting from it for now.