Make sure image module invokes shell commands in the right way

Maybe we could get away with documenting this erroneous behaviour of PHP on Windows and ask people to use the old-style windows directory paths..

i'd like to add that there may be some clues in the way the "rename" function works (or doesn't work) on win32 os. i found some interesting information on it (http://us2.php.net/manual/en/function.rename.php). read the user comments. it exhibits weird behavior on the win32 systems.

Here is a snippet from one of the comments on that page:

snippet:
--------------
To come back on the two word directory rename not working:
Instead of using: rename("c:/program files/test/test.txt", "c:/program files/test.csv")
you can use the old DOS format name to get to the specific file in paths like these.

rename("c:/progra~1/test/test.txt","C:/progra~1/test/test.csv")

all will go fine.
Just remember all long filenames, including the ones with spaces and special characters...
--------------

Please pardon me if my thinking is not correct but could this potentially be a case where a setting in the php.ini is affecting the evaluation of the formula?

The reason that this comes to mind is that unmodified the image.module works on many servers/systems whil it does not on some others.

I don't pretend to understand everything that could be effected but could some php.ini parameter like magic_quotes be the real villan?

If I'm off base please ignore my senseless meanderings...... :-)

Al

bruno:

Not to sidetrack anyone, but the problem as I identified it was not that the rename function was failing but that an earlier piece of code was failing to create the file that the module was later trying to rename. My line 697 rename() failure was a valid error.

I also don't think this is just a Windows issues because I'm running RedHat Linux 7.2.

Commenting out the 2 calls to _image_escape_shell() around line 963 fixed it. The next line of code was silently failing:

$err = exec("$_imagick_convert $filter $source $dest");

The interpolated variables give us:

$err = exec(/path/convert -scale 100 -filter QUADRATIC 'path/image.jpg' 'path/image.jpg');

WITHOUT the previous 2 calls to _image_escape_shell(), we get:

$err = exec(/path/convert -scale 100 -filter QUADRATIC path/image.jpg path/image.jpg);

which works!

I have no idea why the single-quotes cause the exec() to fail.

If you are talking about a different rename() problem on Windows, then please pardon the interruption.
---
Ben

I think I may have previously reported this problem, but am unable to find it now with a search.

Single quotes around the file names cause this code to fail the same way on FreeBSD as well as Linux.

I fixed my site roughly the same way.

Actually with the my patch which moves all the image stuff into a simple api so it is easy to add extra backends see http://drupal.org/node/view/5514 would it not be better to add a backend that uses the php-imagick module which is in pear so we can manipulate the images at a programming level instead of executing a command.

Gordon.

it may no longer be relevant because of what Gordon was mentioning, but in case it still is, this line you wrote that doesn't work:

-------------------
The interpolated variables give us:

$err = exec(/path/convert -scale 100 -filter QUADRATIC 'path/image.jpg' 'path/image.jpg');
-------------------

may only need to be escaped. so 'path/image.jpg' *should* be \'path/image.jpg\'.

or possibly:

$evalExp = "/path/convert -scale..." . "\'" + $imagepath . escape("'" . $imagepathdest . "'")
$err = exec($evalExp);

i would try this first to see if it fixes it rather than just removing the quotes all together. if you have spaces in your path then you could (by fixing this bug) create another bug.

i'm more of a javascript guy i'm still new to php but in js you had to escape stuff like this especially in an eval() type expression. what's listed would fail without a doubt in js. what i have listed is probably way off. but the same thing however it is written in php.

PS. i dont want to post a whole forum topic on this question but i went through the php.net website to learn php and i haven't seen the t() function or some other functions like l() that i have noticed throughout all the modules. if you could spare a moment and give me a quick explination of what these specialized functions do i would be better able to help create rather than translate (from what i know in js).

judah

RH 7.x, Durpal 3.4.2, Id: image.module,v 1.74.2.10 2004/02/06 13:22:22

This module is eating my lunch... I've Read through these and other comments numerous times. The preview images show and the image is uploaded to the Drupal root image file. Convert command works on those files from the command line. Everything checks out ok in the admin settings, I've tried commenting out the lines suggested, but I'm still stuck with:

============
warning: rename(images/tmp/tmpthumb_41d4a531cd5da42521a1dbf792c3f0db.jpg,images/thumbs/thumb_41d4a531cd5da42521a1dbf792c3f0db-23.jpg): No such file or directory in /home/virtual/site4/fst/var/www/html/tiva/modules/image.module on line 697.

Cannot save image.
============

The absolute path that satisfies the the admin settings is:

/home/virtual/site4/fst/usr/X11R6/bin/convert

although convert at the command line works without the full path.

As mentioned in the other thread I've got imagemagick regular galleries set up on ohter sites on the same server and they work flawlessly. I'm new to Drupal but have got other modules working but this one is kiling me.

Still at it 24 hours later, tried commenting out the lines in the 960's with no change.

I get the images uploaded with no thumb and the error message below. Linux server (see previous post for environment details).

Any help or guidance might salvage our use of Drupal which seems like it has a lot of great things going for it.

This and the subscription module are stopping me dead in my tracks. I figured if I could get install and do lots of mods with phpbb, get Gallery with Imagmagick going, and PostNuke with its share of weirdnesses I'd be able to work with what seems like a very cleanly designed Drupal. I'm bummed by this image and subscription modules failure on a server where the systems mentioned above work well. I had a Monday (tomorrow) deadline for a demo that I thought would impress a nonprofit with a better way to handle their Intranet that is fast looking like history.

==================================
Error message:

warning: rename(tmp/tmpthumb_b0b952b8ee3c0b1a2ef747d42605b507.jpg,images/thumbs/thumb_b0b952b8ee3c0b1a2ef747d42605b507-41.jpg): No such file or directory in /home/virtual/site4/fst/var/www/html/tiva/modules/image.module on line 697.

==================================
Image admin check page:

Setting Status
Default image path OK
Default thumb path OK
Temporary image path OK
ImageMagick convert OK
GD Library available (version 2) - supported formats: JPEG, PNG, WBMP
Jhead disabled
Image vocabulary assigned

==================================

Default image path: images/
Default thumb path: images/thumbs/
Temporary image path: tmp/
Imagemagick Convert path: /home/virtual/site4/fst/usr/X11R6/bin/convert

==================================
Lines 696-698

// Rename Thumbnail
if (!rename(_image_tempthumbname($node), $node->thumb_path)) {
die(t("Cannot save image."));
==================================
Lines 959-965

// 040 = space
$filter = preg_replace("/[^A-Za-z0-9\.\-\+\040]/","",$filter);
$source = _image_escape_shell($source);
$dest = _image_escape_shell($dest);
$err = exec("$_imagick_convert $filter $source $dest");

return $err;

gatezone,

you said you are using, "RH 7.x, Durpal 3.4.2, Id: image.module,v 1.74.2.10 2004/02/06 13:22:22 "
i think for drupal you meant, "4.3.2" but anyway, can you try to update your version to the cvs version? or possibly make sure that you are not crossing the cvs version of image.module with the 4.3 image.module. in other words make sure you are using the module version with the drupal version you have installed.

did you try to install the imagemagic in the root directory like i did? what i did worked without commenting out the lines etc. i'm a programmer. i can debug things to find the exact problem. but in this case i was in a hurry plus it's not my code, i'm still learning the ins and outs. i installed imagemagic to the root directory of the server i was on and made the directory for image magic no more than 8 characters long. why? because some systems, apis and some stuff in the past had limitations and not all of that stuff has been updated. and some stuff in programming has set length limits and gets truncated. whatever. i installed it into d:/imagem and then made an absolute path to it, "d:/imagem/convert.exe". this was on drupals admin page > image module > config. thats when it worked for me. i spent a couple days on it as well. try not using random image file names too. and try to using paths with no spaces or funky characters in it. or file lengths with more than 8 characters. try with the limitations i mentioned here and then work up. add the features until you see what breaks it. then list that here.

judah

Thanks for the response - it has been a long so-called weekend:

"...using, "RH 7.x, Durpal 3.4.2, Id: image.module,v 1.74.2.10 2004/02/06 13:22:22 "
i think for drupal you meant, "4.3.2" but anyway, can you try to update your version to the cvs version?"

-> Correct, I am using 4.3.2 amd Image module 4.30 both downloaded from main download page here. I think these are as compatible as they can be...?

"...did you try to install the imagemagic in the root directory like i did? what i did worked without commenting out the lines etc. i'm a programmer. i can debug things to find the exact problem. but in this case i was in a hurry plus it's not my code, i'm still learning the ins and outs. i installed imagemagic to the root directory of the server i was on and made the directory for image magic no more than 8 characters long."

-> I'm on a Linux box where I already have Gallery (Web program that heavily uses Imagemagick) running on server and it works perfectly plus I'm *not* a programmer ;-) and Imagemagick installs seem like a whole new world I'd rather not have to learn - and as said above other systems that rely on it work great on the server as it is configured. I don't know that the 8 character issue should exist in Linux environment?

"....why? because some systems, apis and some stuff in the past had limitations and not all of that stuff has been updated. and some stuff in programming has set length limits and gets truncated. whatever. i installed it into d:/imagem and then made an absolute path to it, "d:/imagem/convert.exe". this was on drupals admin page > image module > config. thats when it worked for me. i spent a couple days on it as well. try not using random image file names too. and try to using paths with no spaces or funky characters in it. or file lengths with more than 8 characters. try with the limitations i mentioned here and then work up. add the features until you see what breaks it. then list that here."

-> Yesp I'm using an absolute path (/home/virtual/site4/fst/usr/X11R6/bin/convert) that is verified on the admin image page. I've tried file names as well as the random file names. From my non-programmers point of view it seems like the code doesn't understand the directory structure even though the admin page appears to agree with the 'registered' path names. Pretty basic stuff in terms of what I think would be called a defined variable that needs to match with the path names entered in the configuration screen.

Since I can run 'convert' from just about anywhere I don't know if the absolute path name is screwing things up even though the image module admin image page show everything to be configured in a useable way. Temp files and image files show up in their respective directories it is just the thumbs that don't which to me points back to that specific code or to the way it is 'calling' or referring to the 'convert' path. I just don't know how to fix it... GZ

From the command line from within the image directory I can run:

convert -scale 100 -filter QUADRATIC image.jpg thumbs/thumb-image.jpg

or from the root of the Drupal directory:

convert -scale 100 -filter QUADRATIC images/image.jpg images/thumbs/thumb-image2.jpg

and a perfect thumbnail is created which tells me that image magick is setup to run correctly, but it doesn't run correctly as it is told to run from within image.module, or with the parameters I've entered into the admin page for the module.

If instead of convert I use /home/virtual/site4/fst/usr/X11R6/bin/convert which an absolute path that the admin image module tests out "ok" I get the following error which sounds a lot like the error in Drupal:

"error while loading shared libraries: libMagick.so.5: cannot open shared object file: No such file or directory"

So my simple brain says the 'absolute path' that the module *likes* may not be the correct one, and maybe it can read that directory and can find the command there but it can't execute it correctly on the files in question. Sorry I'm no programmer but trying to figure this out. GZ

gnash, gnash, pull, pull...;-)

Pardon the language but - problem f'ing solved. Fropm the perspective of a four day old newbie it is heartening that I was able to eventually figure it out - I HOPE it helps someone one else. The answer for me is don't believe the fucking GUI if the logic doesn't make sense to you!!!

The correct path for the convert path for me is simply "convert" because it runs from virtually (he he) any directory on the server if the operator/tion has the correct permissions. The absolute path that the GUI admin panel liked was incorrect for the exection on the 'local' non absolute files. At least that is what makes sense to me.

Maybe the language or the function of this setting in the admin image verifier could be changed to reflect the necessary functionality instead of saying 'absolute path' which is confusing to someone like myself who thinks I've got to point it to the bottom 'turtle' in the rootiest of the root directories all the way up.

Man it is good to see that stinking little thumbnail image! And it ain't even sunrise here in Austin yet ;-).

GZ

just for clarification tell me exactly what you did (or what you entered), on what field, on what page and how you have your site setup, system config, permissions and all. thanks,
judah

These are the settings that worked for me

==================================
Image admin check page:

Setting Status
Default image path " OK"
Default thumb path " OK"
Temporary image path " OK"
ImageMagick convert "DOES NOT EXIST - fix in Site Configuration"
GD Library available (version 2) - supported formats: JPEG, PNG, WBMP
Jhead disabled
Image vocabulary assigned

==================================

Default image path " image/"
Default thumb path "image/thumbs/"
Temporary image path "image/tmp/"
ImageMagick convert "convert" [this gives the above error in the admin verification page - but it works!

I think the key, in my case has to do with using imagemagick from within a directory that can see and write to directories being used. The error message turns out to be pretty literal. Works like a charm now. The 'scarecrow' message in the admin verification window has to be ignored. If it could recognize the working configuration it would be good.

This is on a server I control with virtual domains so imagemagick is available to all the local domain spaces, but the absolute path doesn't work correctly in this environment, or it isn't the correct terminology. I'd also suggest changing the word "resolution" in the thumbnail settings as I think 'dimensions' would be more accurate. Hope this helps the next guy in my shoes! GZ

OK folks. For all of us who have had problems with image.module not creating thumbnails with ImageMagick on Windows. I have found the problem and it has nothing to do with the module itself.
The problem is twofold.

1) You must run ImageMagick from its installed directory without changing the name of the directory. It seems that when ImageMagick runs it expects it's config file to live in a prescribed place (c:\Progra~1\ImageMagick-5.5.7-Q8\cofic/etc..."). Maybe there's a setting in a file that could be changed but I can't find it.
My problem was that I had changed the name of the directory to ImageMagick from ImageMagick-5.5.7-Q8

2) You have to use the DOS style path name to the convert.exe (c:\Progra~1\ImageMagick-5.5.7-Q8\convert.exe rather than c:\Program Files\ImageMagick-5.5.7-Q8)

This is the solution that worked for me
Good Luck!

I believe this was fixed when I integrated Gordon's version of image.module on July 28.