#443 gm mogrify: option -output-directory is utterly (and dangerously!) broken

[Gonzales Woods]

I tried graphicsmagick as a (more secure?) replacement for imagemagick. As the gm aliased tools are said to be compatible to those of imagemagick, I thought my scripts should continue to run just fine. They didn't, because imagemagick's -path option is missing.
I tried using -output-directory instead, despite its strange behaviour of trying to append parts of the input path.
As a workaround I called gm mogrify from the directory where the input file resides. The command is:

mogrify -output-directory /srv/www/www.some.domain/some/subdirectory [processing options] filename

Note that the filename has no extension, and that the output directory contains dots.
The command succeeded and I expected to find the output in /srv/www/www.some.domain/some/subdirectory/filename.jpg.

However, the file was actually written to /srv/www/www.some.jpg!
gm obviously tried to remove a file extension from the output directory (why?!) and completely dropped the actual filename.

This makes no sense, is totally unexpected and is, as I think, really dangerous, as it writes to existing locations where it absolutely should NOT write to at all.

This is graphicsmagick 1.3.25-8 on Debian Stretch.

[Bob Friesenhahn]

I have not been able to reproduce this problem. Is it possible that your path components are UTF-8 strings (e.g. contain extended non-ASCII characters encoded as UTF-8)?

% mogrify -verbose -output-directory /srv/www/www.some.domain/some/subdirectory crap
MogrifyImages (0x83db008->crap): -verbose -output-directory /srv/www/www.some.domain/some/subdirectory
  MogrifyImage (0x83db008->crap): -verbose -output-directory /srv/www/www.some.domain/some/subdirectory
crap JPEG 800x1203+0+0 DirectClass 8-bit 71.0Ki 0.020u 0m:0.017180s (53.4Mi pixels/s)
crap=>/srv/www/www.some.domain/some/subdirectory/crap DOMAIN/SOME/SUBDIRECTORY/CRAP 800x1203+0+0 DirectClass 8-bit 71.0Ki 0.000u 0m:0.000281s (3.2Gi pixels/s)
mogrify mogrify: Unable to open file (/srv/www/www.some.domain/some/subdirectory/crap) [No such file or directory].

[Bob Friesenhahn]

The only way I could see something unexpected happening is if there are multi-character UTF-8 characters in the path. GM still does not parse individual UTF-8 characters while parsing paths.

I am unable to reproduce the problem given the obviously made-up paths provided with this report.