CODEWITHSUNDEEP
variablesapplescript
user7439349
user7439349

Reputation: 37

compare variables in Applescript error?

I have a program that checks then number of files in a selected location and then displays them. But when I tried to incorporate this into another program it bugs. Originally it worked but now it is saying something that is true is false.

set variable1 to do shell script "cd /Volumes; ls | wc -l"
display dialog variable1

This was the original program and it told me the amount of files in my volumes folder was 3.

set variable1 to do shell script "cd /Volumes; ls | wc -l"
variable1 = 3

But then I tried to incorporate it into my new program and it told me it was false!!!???

please if you can, help me as this is incredibly frustrating. Any help is great and thanks in advance!:)

Upvotes: 2

Views: 774

Answers (1)

foo
foo

Reputation: 249

Languages like AppleScript are stupidly pedantic about data types (i.e. the mechanics of how data is represented rather than what it actually means). The do shell script command returns a value of type text (aka string, Unicode text) but then your second line compares it against a value of type integer:

"3" = 3

In a sane, humane world, this comparison would return true because what you mean is obvious. Alas, the programming world is far from sane and rarely humane, and requires a level of pedantry that reduces most human beings to inchoate frustration. In this case, before you try to compare the two values you must ensure both are the same (or equivalent) type. For instance, if you want to perform a numeric comparison:

set variable1 to (do shell script "cd /Volumes; ls | wc -l") as integer
variable1 = 3

AppleScript is doubly confusing here because sometimes it performs that conversion automatically (coercion), while other times it does not, in which case you must use its at operator to explicitly convert (cast) the value yourself.

...

Oh, and the rules by which AppleScript performs numeric comparisons are different to the rules by which it performs textual comparisons, so even in situations where it will "helpfully" coerce values for you you need to be extra alert to the type(s) of the values you are working with, otherwise you can easily be caught out by even more devious and confusing bugs.

For example:

34 > 5 --> true

This first test returns true as expected, as the number 34 is greater than the number 5.

"34" > "5" --> false (?)

Text comparison compares two text values character-by-character, thus the second test returns false because the "3" comes before, not after, "5".

Furthermore, unlike the is-equal (=) and is-not-equal (≠) operators, the >, <, ≥, and ≤ operators do coerce their operands to the same type before comparing them:

34 > "5" --> true

"34" > 5 --> false

In both cases, the operator coerces its right operand to the same type as its left operand before comparing them according to numeric (in the first case) or textual (in the second) rules. This sort of behavior may be politely described as a language design flaw or "wart".

If you're even unsure what type of value the left operand will be, but want to make absolutely sure it is compared using the correct set of rules, apply the appropriate coercion to it first:

(variable1 as number) > 5

(variable1 as text) > "5"

Upvotes: 4

Related Questions