A repeat can help :
gmic v 3 run ' repeat 3 sp done -o test.png repeat 3 delete test_00000$>.png done'
This will spawn 3 sample images, save them to disk as test_xxxxxx.png and delete them. (A very useful pipeline indeed )
A repeat can help :
gmic v 3 run ' repeat 3 sp done -o test.png repeat 3 delete test_00000$>.png done'
This will spawn 3 sample images, save them to disk as test_xxxxxx.png and delete them. (A very useful pipeline indeed )
For wildcard, use delete
in conjunction with files
:
$ gmic files \*.jpg delete ${}
This should delete files like temporary_000010.jpg
in the directory I run gmic. At least on my Mac, it does not. I will try and figure out why tomorrow.
Good morning @David_Tschumperle. Interesting. I ave created (toch) s fit temp.jpg
gmic files t\*.jpg delete ${}
does not remove the filegmic files "t*.jpg" delete ${}
does not remove the fileIn both cases I get:
[gmic]./ Start G'MIC interpreter (v.3.3.0).
[gmic]./ Get list of files and folders from location 't*'.
[gmic]./ Delete file '' (1 file).
[gmic]./ End G'MIC interpreter.
So, the files
command seems not to return the files starting with t.
I then have added the following to my .gmic file:
md:
e "--- Generating files --- "
x "touch tempo touching tempo_ tempo_xx"
x "ls"
echo "--- Executing 'files t\\\* delete ${}' ---"
files t\* delete ${}
x "ls"
echo "--- Executing 'files \"t*\" delete ${}' --- "
files "t*" delete ${}
x "ls"
and the last command files "t*" delete ${}
deletes all files starting with a t.
Odd… It seems to be a question of escaping and the “non-interactive” use…
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.
Thanks, @grosgood. That makes all sense. Much appreciated.
I am nearing completion… the film strips are created front to back. Just need to do some more testing.
Is there, by the way, a way of checking if I am in the first or last iteration of a repeat statement? I have to duplicate quite some code at the moment to deal with the last iteration …
Query $>
or $<
as necessary.
Let:
foo :
doitfor=$1
repeat $doitfor
if $><{$doitfor-1}
echo {$doitfor-($>+1)}" items to go!"
else # doitfor clocks out
echo "Last round! Closing up now!"
fi
done
then:
gmic -m foo.gmic foo 10
[gmic]./ Start G'MIC interpreter (v.3.3.0).
[gmic]./ Import commands from file 'foo.gmic', with debug info (2 new, total: 4661).
9 items to go!
8 items to go!
7 items to go!
6 items to go!
5 items to go!
4 items to go!
3 items to go!
2 items to go!
1 items to go!
Last round! Closing up now!
[gmic]./ End G'MIC interpreter.
Does this help?
It did… and my first new command seems to work. Thank you.