Legacy ImageMagick Discussions Archive

Version: ImageMagick 6.8.8-1 Q16 x86_64 2014-08-29 http://www.imagemagick.org
SLES 12

I don't know if it is a bug or caused by filename processing from Imagemagick

1. Create two files test_1.png and test_10.png
2. Execute convert "test_1.png" -verbose "test_1[160x90].png"

Expected behaviour: test_1[160x90].png should be created, but test_10.png is overwritten instead.

3. Delete test_10.png
4. Execute convert "test_1.png" -verbose "test_1[160x90].png" again

This time test_1[160x90].png is created.

This very strange in my eyes. If output filename processing is the reason shouldn't it be at least the same output name ? Why does another existing file influence the output filename.

Did i oversee any commandline parameters to switch off output filename processing.
Square brackets have a special meaning in Imagemagick, any way to escape them so imagemagick handles them as normal characters ?

I tried your tests on IM 6.9.1.2 Q16 Mac OSX
The first two lines work fine
The third line does not over write any of the previous two and does not produce any output ( I think because test_1.png already exists and [...] are input file modifiers.)

But
does work since there is no image test_2.png already.

fmw42 wrote:I tried your tests on IM 6.9.1.2 Q16 Mac OSX
The first two lines work fine
The third line does not over write any of the previous two and does not produce any output ( I think because test_1.png already exists and [...] are input file modifiers.)

It probably did overwrite test10.png. To the shell, "[160x90]" means one character matching any of 1,6,0,x,9,or 0. The problem is that the shell is interpreting the commandline before passing it to "convert".
Here's a workaround:

Thanks the workaround works as expected, but in my application i'm using im4java wrapper which makes things more complicated

Not sure the shell is doing the changes, commands like
cp "test_1.png" "test_1[160x90].png"
work as expected on don't show this behaviour, if the shell would do the interpreting, shouldn't it cause the same kind of issue with other commands ?

You can see the arguments the shell passes to convert with "-debug all". (This gives loads of output; some other debug gives less, but I forget which include the command-line args).

jviebig wrote:Thanks the workaround works as expected, but in my application i'm using im4java wrapper which makes things more complicated

Not sure the shell is doing the changes, commands like
cp "test_1.png" "test_1[160x90].png"
work as expected on don't show this behaviour, if the shell would do the interpreting, shouldn't it cause the same kind of issue with other commands ?

In this case, the shell respects the quotation marks, just as in the workaround I presented. When the brackets are included in "convert" arguments, there is some confusion because they mean different things to the shell and to "convert". For the behavior you want (and expected), the brackets need to be "escaped" somehow so the shell doesn't see them as anything special. I tried a few things but didn't succeed (for example, backslashes prevent the shell from processing the brackets, but then "convert" sees them too and they end up in the output filename. As you remarked, wrapping everything in java is just going to make things even more confusing. If it were my project I'd probably give up on that naming scheme and use test_1_160x90.png instead to avoid the issue (and possible future breakage) entirely.

I still don't think the shell does this.

I can do things like this: cp 'test.png' '*.png' (and also cp 'test_1.png' 'test_1[160x90].png') which creates a file *.png so the shell is definetely not processing parameters in ' ' at all

so if i do:
convert 'test_1.png' -verbose 'test_1[160x90'].png'
, still test_10.png is overwritten. But the shell will not process the parameters so imagemagick is doing this.

debug all gives this:

2015-04-29T12:02:25+02:00 0:00.000 0.000u 6.8.8 Configure convert[11347]: utility.c/ExpandFilenames/941/Configure
Command line: convert {-debug} {all} {test_1.png} {-verbose} {test_10.png}

But after looking at the source code, this ouput is done After "ExpandFilenames" which seems to do all kinds of "magic" to the filenames but imagemagick does not seem to have a way to escape. Unfortunately there is no output before the processing

Here is one more hint that the shell is not doing this:
Enabled shell debugging with set -x

If i do something like this where * is definetely processed by the shell:
convert -debug all 'test_1.png' -verbose *.png
I get (bash debug message):
+ convert -debug all test_1.png -verbose '*.png' test_1.png test_10.png
Bash processes the name as expected

If i do:
convert -debug all 'test_1.png' -verbose test_1[160x90].png
I get (bash debug message)
+ convert -debug all test_1.png -verbose test_10.png
Bash processes the name as expected

if i do:
convert -debug all 'test_1.png' -verbose 'test_1[160x90'].png'
I get (bash debug message)
+ convert -debug all test_1.png -verbose 'test_1[160x90].png'
Bash does not process the name as expected, but imagemagick does

So in this last example the shell does not process the filename, but then imagemagick does it.

Changing the name scheme sounds like a good advice, but the naming scheme is already used in multiple installs for years, and this is a special case where this naming problem happens.