Legacy ImageMagick Discussions Archive

I still cannot tell, so please try these and show me the scripts and output. Do they run if you just copy and past the following into your terminal window?

width=$(convert rose: -format "%w" info:)
echo "width=${width}a"
xx=$((width-1))
echo "xx=${xx}b"

width=$(convert rose: -format "%w" info: 2>&1)
echo "width=${width}a"
xx=$((width-1))
echo "xx=${xx}b"

width=$(convert rose: -format "%[fx:w]" info:)
echo "width=${width}a"
xx=$((width-1))
echo "xx=${xx}b"

width=$(convert rose: -format "%[fx:w]" info: 2>&1)
echo "width=${width}a"
xx=$((width-1))
echo "xx=${xx}b"

Are your scripts using unix line endings or windows line endings?

I am using the UNIX line ending built into Notepad++

Here is the image fro the output.

very strange, it is not echoing properly

it is showing aidth=70 and not width=70a. It is taking the ending "a" and modifying the variable?

What does it show for

width=$(convert rose: -format "%w" info:)
echo "width=${width}"
xx=$((width-1))
echo "xx=${xx}"

and for

width=$( convert rose: -format "%w" info: )
echo "width=${width}"
xx=$((width-1))
echo "xx=${xx}"


It is hard to tell from your listings above, but just to be sure, there is not space between $ and (convert ...)

No spaces at all.

I did notice a space in the script below
Here is a new pic.

I am at a loss to know what is really going on. I have notified the IM developer to check if there is something odd in the IM Cygwin package. Barring that, the only thing I can do is to replace all such IM calculations with bc calculations. Since you have been patient with all these tests, I will try to modify 3Dcover and 3Drotate and you can try those. We can go from there. I have to go out for a while and will try to get back to this later this afternoon. Perhaps I will hear back from the IM developer if he has a way to test the IM Cygwin package.

You might want to get on one or more of the Cygwin discussion forums and search to see if any one else is having trouble running IM and IM unix shell scripts.

Try this last one test, to see if it shows the odd variable echo behavior

width=$(convert rose: -format "%w" info:)
echo "width=;${width};"
xx=$((width-1))
echo "xx=;${xx};"

I am adding semicolons to see if there are any hidden characters. Or if the echo gets corrupted again.

Thank you for the help.

The IM developer, Magick, said he would try some of our tests on his version of Cygwin. So I am waiting to hear back from him. Perhaps he will find something odd about the IM Cygwin package.

The fact that you get length 2 for a variable assigned the value of 1 is very strange. It would seem that IM may be returning some extra hidden character. Perhaps a new line in addition to the numeral. So the variable may be treated as a string and not a numeral.

Try this to remove any line feeds from the convert command

width=$(convert rose: -format "%w" info: | tr -d "\n")
echo "width=${width}"
xx=$((width-1))
echo "xx=${xx}"

In the mean time, I have converted the scripts to use bc calculations. If you want to give them a try, email me directly at fmw at alink dot net

Looks like the same issue

echo "------Script 1----------"
width=$(convert rose: -format "%w" info: | tr -d "\n")
echo "width=${width}"
xx=$((width-1))
echo "xx=${xx}"

Code: Select all

------Script 1----------
width=70
")syntax error: invalid arithmetic operator (error token is "
xx=

Too bad. I really thought that might be the issue.

fmw42 wrote:Try this to remove any line feeds from the convert command

width=$(convert rose: -format "%w" info: | tr -d "\n")
echo "width=${width}"
xx=$((width-1))
echo "xx=${xx}"

The extra newline is normal, and most programs generate it... including "bc". In this case it is generated because info: will always add a newline after processing -format once for each image.
For example... If the newline was not added you would have gotten "70640" This is historical, and for ease of use for users, otherwise the -format setting needs a "\n" added to the format string.

An alternative is use -print, whcih does not add extra chars as it is applied once only (even with multiple images) Note there is no extra newline in the above though it is hard to demonstrate that on the forum.


Hmmm the $(....) shell syntax seems to automatically strip extra newlines! That is strange as the bash manual clearly states...

Embedded newlines are not deleted, but they may be removed during word splitting.

Adding a extra character after the newlines "\n" however did casue the newline to be retained. So it looks like newlines on the end in my version of bash are stripped automatically. adding more newlines after the "A" in the last example were also striped, though the ones in between were retained.

However, shell integer arithmetic expression handling should also ignore white space, including newlines. For example... Perhaps your BASH is too old for $((..)) or it isn't BASH at all but simpler Bourne (Posix) shell!

hmmm... "Dash" on Linux systems is a Posix Shell (with saome berkley extensions), though it has $((...)) too,
and works as expected.

Trying old Solaris Bourne Shell "sh" (Sun/Oracle UNIX machine) gives me the error

syntax error: `xx=$' unexpected

While "zsh", "ksh", works fine.


So really what version of BASH is cygwin using???? Must be pretty old.
Can you try the above tests?

My version is

Something is getting corrupted between IM string formats and fx calculations stored to a variable with Cygwin. They look OK, but when trying to do integer arithmetic, one gets an error message. See above

Everything works fine if the IM computations are replaced with bc calculations.

It is not the new line as I had hoped.

I have reported this to Magick and he said he would check it. If it works for him, then it might be a version of Cygwin issue. Otherwise, two users have reported issues to me with creating variables from IM calculations (fx or string formats). One user was on Windows 7 and the other on Windows 8 (this was Wolfgang Hugemann, who wrote the documents at http://www.imagemagick.org/Usage/windows/. He is now confirming that my scripts do not run successfully and the issue points to IM calculations stored in variables.

I must say that this seems rather new. This was not always the case. My scripts used to work under Cygwin, if bc was included and the IM calculations never were a problem.


Anthony,

PS. the document listed above needs to be amended slightly to point out that bc needs to be included in Cygwin and can be installed as an option with the installation. The nominal install does not include it. But it is selectable from the install panel.

See my last post...
I was still editing it!

fmw42 wrote:PS. the document listed above needs to be amended slightly to point out that bc needs to be included in Cygwin and can be installed as an option with the installation. The nominal install does not include it. But it is selectable from the install panel.

DONE, should appear in a few hours. (if server upgrades has not broken anything)

Perhaps your BASH is too old for $((..)) or it isn't BASH at all but simpler Bourne (Posix) shell!

That syntax works fine if the variables used in the $((...)) are computed from bc, but fail if the variables are computed from IM.

For example:

This works

angle=25
# compute crop of input into front and side
sign=`echo "$angle>0" | bc`
echo "sign=$sign"
xx=$((sign+1))
echo $xx


But this does not

angle=25
# compute crop of input into front and side
sign=$(convert xc: -format "%[fx:$angle<0?0:1]" info:)
echo "sign=$sign"
xx=$((sign+1))
echo $xx

The odd thing is that sign from the IM calculation (which should be 1) is coming out of character length=2

what character. "return" or "newline"

It may be that BASH knowns to handle "newline", but not "return", and PC text file format uses "returns" for end of line where UNIX and MacOSX uses "newline"

Feed the bc output and IM output into "od" and see what the characters are.