Possible bug with filename handling (Windows x86)

[Rekrul]

I don't know if this is a legitimate bug or just some quirk of the command line that I'm not aware of. It seems like a bug to me.

To start with, I have an old system with WinXP on it, so I'm using this release;

ImageMagick-7.0.8-59-portable-Q16-x86.zip

I've been trying to write a script that will go through a directory full of unknown image files and rename them based on their actual width. Since the directory may contain GIF files with multiple frames, the only reliable way to get the width is to tell it to only look at the first frame. Otherwise the width might be reported as "450450450450450", etc. The problem is that the command line fails if the filename happens to contain "%%" and you include the option to only check the first frame.

For example, these work;

Code: Select all

Identify -format %w "Test.gif"[0]

Identify -format %w "Test.gif[0]"

If the name contains "%%", the command will work if you leave off the "[0]";

Code: Select all

Identify -format %w "T%%est.gif"

However if you include "[0]" either inside or outside of the quotes, the command fails;

Code: Select all

Identify -format %w "T%%est.gif"[0]

Identify -format %w "T%%est.gif[0]"

In order to make them work, you have to add an extra "%";

Code: Select all

Identify -format %w "T%%%est.gif"[0][/b]

Identify -format %w "T%%%est.gif[0]"[/b]

Since this is being used inside a script, I don't know ahead of time what the filenames will contain. While I admit that it's unlikely that any filename will contain multiple "%"s I can't rule it out. I thought that enclosing the filenames in quotes would protect them, but for some reason, the addition of "[0]" seems to nullify the effect of the quotes and it thinks the percent signs are part of the parameters.

I'm inclined to consider this a bug since it has no problem with the filename when you omit "[0]", no matter what (legal) characters it contains. I wouldn't think that a parameter (flag, whatever) to tell it to only look at the first frame of a file would change how it handles the filename.

[snibgo]

Since this is being used inside a script, I don't know ahead of time what the filenames will contain.

I agree that IM should correct this problem, but I don't agree with your statement. What happens if you have a filename like "my.gif[0]"?

If you accept files from any users, it is good practise to ensure that filenames contain no special characters such as *?[]"!^&()%'#<> and space. Personally, I accept alphanumeric and - and _ and nothing else.

[Rekrul]

I agree that IM should correct this problem

So it's an actual bug? Do the developers check this forum or should I report it elsewhere?

but I don't agree with your statement. What happens if you have a filename like "my.gif[0]"?

Then it wouldn't be recognized as a GIF file by my script or Windows because the extension .GIF[0] doesn't match any known image file type.

If you accept files from any users, it is good practise to ensure that filenames contain no special characters such as *?[]"!^&()%'#<> and space. Personally, I accept alphanumeric and - and _ and nothing else.

Most of the images were saved off the web. I'm a hoarder, if I see an image that I like, I save it. Sometimes I grab entire sets of images at a time. I put them in directories and when I have enough, I archive them to a DVD. Why? Because it's what I like to do. With some exceptions, I like to keep the original filenames. The width portion of my script actually relabels images saved from Tumblr to have the correct width indicator in the name, according to Tumblr rules. It also checks for incorrect extensions.

When saving bunches of images, I can't always spot problematic filenames. I try to watch for really long ones since 102 characters is the limit for burning, but some always sneak through. I made checking for such names part of my script.

The whole idea behind having a script to do this is that I can just point it at a bunch of directories and let it fix the extensions, Tumblr sizes and check for names that are too long, all without me having to do any prep work.

[magick]

Thanks for the problem report. We can reproduce it and will have a patch to fix it in GIT master branch @ https://github.com/ImageMagick/ImageMagick later today. The patch will be available in the beta releases of ImageMagick @ https://www.imagemagick.org/download/beta/ by sometime tomorrow.

[Rekrul]

Thanks for the problem report. We can reproduce it and will have a patch to fix it in GIT master branch @ https://github.com/ImageMagick/ImageMagick later today. The patch will be available in the beta releases of ImageMagick @ https://www.imagemagick.org/download/beta/ by sometime tomorrow.

Thank you for the quick response.

[Rekrul]

Just tried the new beta and it seems to work great. Thanks!