Page 1 of 1

possible bug -function polynomial IM 6.7.9.10 Q16

Posted: 2012-10-13T16:04:08-07:00
by fmw42
IM 6.7.9.10 Q16 Mac OSX Snow Leopard

Clarification please if this is a bug or I am doing something wrong.

The following seems to fail. Though I use this same technique for other operations in my scripts without such error message.



proc="-function polynomial '1 0 0'"
convert rose: $proc 1tmp.png

convert: unable to open image `0': No such file or directory @ error/blob.c/OpenBlob/2638.
convert: no decode delegate for this image format `0' @ error/constitute.c/ReadImage/550.
convert: unable to open image `0'': No such file or directory @ error/blob.c/OpenBlob/2638.
convert: no decode delegate for this image format `0'' @ error/constitute.c/ReadImage/550.

Re: possible bug -function polynomial IM 6.7.9.10 Q16

Posted: 2012-10-15T17:30:20-07:00
by anthony
I would say it is a quoting problem.

The shell is not seeing the single quotes.

Re: possible bug -function polynomial IM 6.7.9.10 Q16

Posted: 2012-10-15T17:36:57-07:00
by fmw42
Anthony wrote:I would say it is a quoting problem.

The shell is not seeing the single quotes.

Possibly, but it works if I use comma separation.

This works
proc="-function polynomial '1,0,0'"
convert rose: $proc 1tmp.png


But not if I add spaces with the commas

This does not
proc="-function polynomial '1, 0, 0'"
convert rose: $proc 1tmp.png


However, as one line it works with spaces with or without commas.

This works
convert rose: -function polynomial '1 0 0' 1tmp.png

Re: possible bug -function polynomial IM 6.7.9.10 Q16

Posted: 2012-10-15T19:10:59-07:00
by anthony
Comma stop the argument being split due to the lack of the quotes.


The shell is basically handling quoting before variable expansion.

So the shell sees the single quotes in the variable as argument, not quotes so you see

Code: Select all

proc="-function polynomial '1, 0, 0'"
convert rose: $proc 1tmp.png
being evaluated as...

Code: Select all

'convert'    'rose:'  '-function'   'polynomial'    '\'1,'    '0,'    '0'  '1tmp.png'
so -function option see its two expected arguments as polynomial and '1, (shell already did quotes before) and IM will ignore the single quote as being irrelevant to a number list. As IM executes the equivelent of -function polynomial 0.

The next two arguments to IM, 0, and 0 are non-options, so are thought of image filenames. Thus the errors you see.

The solution is to ask the shell to expand quote and substitutions once before trying to do it a second time by using the shell built-in eval.

Code: Select all

eval "convert 'rose:' $proc '1tmp.png'"
The eval performs the substitutions, and the shell then executes

Code: Select all

convert 'rose:' -function polynomial '1, 0, 0' '1tmp.png'
and everything is as you want it to be.

WARNING: the extra quotes "..." is important to prevent the shell doing other things twice (like backslashes of parenthesis).

To see what the shell will see after the eval change eval to echo

Re: possible bug -function polynomial IM 6.7.9.10 Q16

Posted: 2012-10-15T20:05:27-07:00
by fmw42
Thanks for the clarification. I unfortunately did not look at your Usage pages before I tried the command without commas and it worked until I made a variable for it. It is easy enough to replace the variable definition with commas as -function polynomial '1,0,0' and that works. So it really is a non-issue going forward for me. However, if you think appropriate, then perhaps a comment in your Usage pages might be in order to warn that this kind of thing does not work with spaces w/ or w/o commas when forming a variable.

Re: possible bug -function polynomial IM 6.7.9.10 Q16

Posted: 2012-10-15T23:04:01-07:00
by anthony
To me this is a shell usage issue and not a IM issue.

If I did this for every situation I have not exampled, I'd have a shell usage page, rather than a ImageMagick usage page ;-)

If I use it in a example, then of course I'd mention why I used 'eval'.

however it would be easier in IMv7 with magick scripting. make a setting, then use that setting in the command later.